AZ-305 Practice Exam 1
60 questions
Open this course’s practice exams →Microsoft Azure · Public course · v1.0.1
Study Azure solution architecture across identity, governance, data, business continuity and infrastructure with flashcards, explained questions and four practice exams.
596 flashcards · 400 practice questions
Choose topics, then use Flashcards, Learn, Write, Match, Practice Questions or Mock Exam when the course has suitable content.
Unofficial study aid; not affiliated with or endorsed by Microsoft. Original practice questions are not real examination questions and do not guarantee an exam result.
Fixed question sets within this course. Open study modes to take an exam and save results in your browser.
60 questions
Open this course’s practice exams →60 questions
Open this course’s practice exams →60 questions
Open this course’s practice exams →60 questions
Open this course’s practice exams →Architecture foundations and design method
CAF guides organizational adoption and the shared Azure foundation; the Well-Architected Framework evaluates the quality of an individual workload.
Source guide: PDF page(s) 4.
Architecture foundations and design method
Identify business outcomes, functional requirements, measurable quality targets, constraints, dependencies, and operating responsibilities.
Source guide: PDF page(s) 4.
Architecture foundations and design method
A functional requirement states what the system does; a quality requirement states how well it does it, such as checkout latency or availability.
Source guide: PDF page(s) 4.
Architecture foundations and design method
Define a service level objective for a specified user journey, measurement window, and failure conditions.
Source guide: PDF page(s) 4.
Architecture foundations and design method
Define a recovery time objective for restoring acceptable service and a recovery point objective for tolerated data loss measured in time.
Source guide: PDF page(s) 4.
Architecture foundations and design method
Strategy, Plan, Ready, Adopt, Govern, Secure, and Manage.
Source guide: PDF page(s) 4.
Architecture foundations and design method
Business motivations, desired outcomes, and the basis for evaluating the value of cloud adoption.
Source guide: PDF page(s) 4.
Architecture foundations and design method
People, skills, costs, workload priorities, ownership, funding, and the adoption backlog.
Source guide: PDF page(s) 4.
Architecture foundations and design method
The Azure foundation and landing zones needed before workloads are adopted.
Source guide: PDF page(s) 4.
Architecture foundations and design method
Migration, modernization, and building cloud-native workloads.
Source guide: PDF page(s) 4.
Architecture foundations and design method
Guardrails, protection, and operations must evolve as workloads are adopted and optimized.
Source guide: PDF page(s) 4.
Architecture foundations and design method
An architecture and operating foundation with management, identity, connectivity, security, governance, and operational capabilities; it is not a single service.
Source guide: PDF page(s) 4-5.
Architecture foundations and design method
Shared capabilities such as connectivity, identity integration, policy, security, and management for workload environments.
Source guide: PDF page(s) 4-5.
Architecture foundations and design method
Give an application team a governed environment in which to deploy and operate its workload.
Source guide: PDF page(s) 4-5.
Architecture foundations and design method
Shared connectivity and policy ownership differ from application configuration, data, and recovery ownership; gaps otherwise create operational failures.
Source guide: PDF page(s) 5.
Architecture foundations and design method
Reliability, Security, Cost Optimization, Operational Excellence, and Performance Efficiency.
Source guide: PDF page(s) 5.
Architecture foundations and design method
Meeting availability and recovery targets through redundancy, fault isolation, capacity planning, and tested recovery.
Source guide: PDF page(s) 5.
Architecture foundations and design method
Protecting confidentiality, integrity, and availability with verified identity, least privilege, segmentation, encryption, detection, and response.
Source guide: PDF page(s) 5.
Architecture foundations and design method
Getting required business value from spending through rightsizing, waste removal, demand modeling, and total operating cost analysis.
Source guide: PDF page(s) 5.
Architecture foundations and design method
Safe deployment, observation, operation, and improvement through automation, telemetry, runbooks, and controlled change.
Source guide: PDF page(s) 5.
Architecture foundations and design method
Capacity and design that deliver the required user experience as demand changes, based on measured bottlenecks and scaling patterns.
Source guide: PDF page(s) 5.
Architecture foundations and design method
Improving one quality can affect another: extra regional copies improve resilience but add cost and operational work.
Source guide: PDF page(s) 5.
Architecture foundations and design method
A geographic deployment area containing datacenters and regional services.
Source guide: PDF page(s) 6.
Architecture foundations and design method
A separated logical grouping of one or more datacenters within a region with independent power, cooling, and networking.
Source guide: PDF page(s) 6.
Architecture foundations and design method
A zonal resource is placed in a chosen zone; a zone-redundant service distributes supported components across zones according to its service design.
Source guide: PDF page(s) 6.
Architecture foundations and design method
No. A subnet normally spans zones within its region.
Source guide: PDF page(s) 6.
Architecture foundations and design method
No. Logical-to-physical zone mappings are subscription-specific; validate mappings when coordinating cross-subscription deployments.
Source guide: PDF page(s) 6.
Architecture foundations and design method
Azure currently does not charge for that transfer. Additional replicas and supported service tiers can still increase cost.
Source guide: PDF page(s) 6.
Architecture foundations and design method
Regional incidents; it requires routing, data replication, identity and dependency availability, and recovery procedures.
Source guide: PDF page(s) 6.
Architecture foundations and design method
No. Replication and failover are service-specific and must be configured and tested with application recovery.
Source guide: PDF page(s) 6.
Architecture foundations and design method
No. Many regions are unpaired, and service replication choices differ; verify actual destinations and residency.
Source guide: PDF page(s) 6.
Architecture foundations and design method
Guest OS, applications, patching, data, permissions, and much configuration, while Microsoft operates physical infrastructure.
Source guide: PDF page(s) 6.
Architecture foundations and design method
Application code, data, permissions, and relevant security and recovery configuration, despite more platform maintenance moving to Microsoft.
Source guide: PDF page(s) 6.
Architecture foundations and design method
Identity, authorized use, data governance, and application configuration within the service's shared-responsibility model.
Source guide: PDF page(s) 6.
Architecture foundations and design method
SLA is a provider's contractual commitment; SLO is the workload's target; SLI is the measurement used to evaluate that target.
Source guide: PDF page(s) 7.
Architecture foundations and design method
Contracts have different conditions and downtime definitions, and dependencies can share failure modes. Analyze measured user journeys and end-to-end failures.
Source guide: PDF page(s) 7.
Architecture foundations and design method
0.999 × 0.999 = 0.998001, or 99.8001%. This is mathematical intuition, not an application contractual SLA or a reliable availability estimate.
Source guide: PDF page(s) 7.
Architecture foundations and design method
Compute, storage, requests, telemetry, backup, networking, support, licensing, labor, and normal, peak, and recovery operation.
Source guide: PDF page(s) 7.
Architecture foundations and design method
When demand is predictable and the commitment matches expected use; variable workloads may favor flexible consumption.
Source guide: PDF page(s) 7.
Architecture foundations and design method
It may violate residency, require unavailable skills, miss recovery targets, introduce excessive administration, or exceed the budget.
Source guide: PDF page(s) 4.
Monitoring and logging
Choose the operational questions, signals, collection paths, destinations, retention, access, and response process together. A workspace alone does not make a workload observable.
Source: AZ-305 Study Guide.pdf, PDF page(s) 8; reference [I07]. Newly generated study item; human review pending.
Monitoring and logging
Use numeric time series such as CPU, latency, request count, and queue depth for trends, dashboards, and supported threshold alerts.
Source: AZ-305 Study Guide.pdf, PDF page(s) 8; reference [I07]. Newly generated study item; human review pending.
Monitoring and logging
Use timestamped structured records for detailed investigation, audit evidence, correlation, and queries across components.
Source: AZ-305 Study Guide.pdf, PDF page(s) 8; reference [I07]. Newly generated study item; human review pending.
Monitoring and logging
It follows one request through services and dependencies to identify where latency or failure occurs.
Source: AZ-305 Study Guide.pdf, PDF page(s) 8; reference [I15]. Newly generated study item; human review pending.
Monitoring and logging
Activity logs record subscription-level management events. Resource logs record service-specific operations, often including data-plane activity.
Source: AZ-305 Study Guide.pdf, PDF page(s) 8; reference [I08]. Newly generated study item; human review pending.
Monitoring and logging
Supported platform metrics and activity logs are automatic. Resource logs generally need diagnostic settings; guest logs need an agent and collection configuration; application telemetry needs instrumentation.
Source: AZ-305 Study Guide.pdf, PDF page(s) 8; reference [I08]. Newly generated study item; human review pending.
Monitoring and logging
AMA collects supported guest telemetry through its collection configuration. Resource diagnostic logs and application instrumentation use separate collection paths.
Source: AZ-305 Study Guide.pdf, PDF page(s) 8; reference [I09]. Newly generated study item; human review pending.
Monitoring and logging
Monitor availability, error rate, latency, throughput, and saturation, then add dependency and capacity signals. CPU alone does not establish customer impact.
Source: AZ-305 Study Guide.pdf, PDF page(s) 8; reference [I15]. Newly generated study item; human review pending.
Monitoring and logging
Synthetic tests discover externally visible failures; application requests, exceptions, and traces explain the failing path and dependencies.
Source: AZ-305 Study Guide.pdf, PDF page(s) 8; reference [I15]. Newly generated study item; human review pending.
Monitoring and logging
It selects supported resource log categories or category groups and sends them to configured destinations. Select collection breadth according to purpose and volume.
Source: AZ-305 Study Guide.pdf, PDF page(s) 9; reference [I08]. Newly generated study item; human review pending.
Monitoring and logging
When operators need KQL investigation, cross-component correlation, workbooks, and supported log alerts. Plan ingestion, table plans, retention, and permissions.
Source: AZ-305 Study Guide.pdf, PDF page(s) 9; reference [I08]. Newly generated study item; human review pending.
Monitoring and logging
For economical archives, static analysis, or immutable audit retention. Configure lifecycle and immutability and plan how evidence will be retrieved.
Source: AZ-305 Study Guide.pdf, PDF page(s) 9; reference [I08]. Newly generated study item; human review pending.
Monitoring and logging
When an external SIEM or processing system needs a continuous log stream. Design throughput, retention, consumers, and credential protection.
Source: AZ-305 Study Guide.pdf, PDF page(s) 9; reference [I08]. Newly generated study item; human review pending.
Monitoring and logging
Configure diagnostic settings for multiple destination types, such as Log Analytics and Storage. Validate delivery to each destination and justify duplicate ingestion.
Source: AZ-305 Study Guide.pdf, PDF page(s) 9; reference [I08]. Newly generated study item; human review pending.
Monitoring and logging
For a regional monitored resource, Storage and Event Hubs destinations must be in that resource's region. Log Analytics does not have the same destination-region restriction.
Source: AZ-305 Study Guide.pdf, PDF page(s) 9; reference [I08]. Newly generated study item; human review pending.
Monitoring and logging
One setting permits one destination of each type. A resource supports up to five diagnostic settings, allowing additional destinations of a given type through separate settings.
Source: AZ-305 Study Guide.pdf, PDF page(s) 9; reference [I08]. Newly generated study item; human review pending.
Monitoring and logging
Use the documented trusted Microsoft services bypass. A private endpoint alone does not route diagnostic export through the customer's private network.
Source: AZ-305 Study Guide.pdf, PDF page(s) 9; reference [I08]. Newly generated study item; human review pending.
Monitoring and logging
Another subscription is supported with appropriate configuring-identity permissions. Azure Lighthouse supports relevant cross-tenant destination scenarios; tenant access must be designed explicitly.
Source: AZ-305 Study Guide.pdf, PDF page(s) 9; reference [I08]. Newly generated study item; human review pending.
Monitoring and logging
AMA collects supported guest telemetry; a DCR specifies sources, streams, transformations, and destinations; an association connects that rule to the monitored resource.
Source: AZ-305 Study Guide.pdf, PDF page(s) 10; reference [I09]. Newly generated study item; human review pending.
Monitoring and logging
Reuse suitable DCRs across resources, and split rules where operating systems, destinations, sensitivity, or collection requirements differ. Validate with representative generated events.
Source: AZ-305 Study Guide.pdf, PDF page(s) 10; reference [I09]. Newly generated study item; human review pending.
Monitoring and logging
Represent supported servers through Azure Arc and deploy the Azure Monitor Agent extension with the required DCR association.
Source: AZ-305 Study Guide.pdf, PDF page(s) 10; reference [I09]. Newly generated study item; human review pending.
Monitoring and logging
A DCR is collection policy; a data collection endpoint provides configuration and ingestion connectivity for supported scenarios. A DCE is not required for every AMA deployment.
Source: AZ-305 Study Guide.pdf, PDF page(s) 10; reference [I11]. Newly generated study item; human review pending.
Monitoring and logging
Private Link configurations need appropriate DCE and DNS arrangements. Check source-specific requirements and newer DCR ingestion endpoints rather than assuming all paths use a DCE.
Source: AZ-305 Study Guide.pdf, PDF page(s) 10; reference [I11]. Newly generated study item; human review pending.
Monitoring and logging
Supported incoming streams can be filtered or reshaped before ingestion to reduce cost or sensitive data. Discarded data is irrecoverable through that collection path, so preserve required evidence.
Source: AZ-305 Study Guide.pdf, PDF page(s) 10; reference [I09]. Newly generated study item; human review pending.
Monitoring and logging
Use Azure Monitor Agent for supported guest telemetry. The Log Analytics agent retired August 31, 2024; Azure ingestion can stop without further notice after March 2, 2026.
Source: AZ-305 Study Guide.pdf, PDF page(s) 10; reference [I10]. Newly generated study item; human review pending.
Monitoring and logging
Start with one workspace and add boundaries when residency, tenants, access, ownership, region, or cost requirements justify them. A subscription boundary alone does not require a workspace.
Source: AZ-305 Study Guide.pdf, PDF page(s) 10; reference [I12]. Newly generated study item; human review pending.
Monitoring and logging
It can duplicate ingestion and administration. Evaluate shared collection, access isolation, Sentinel billing, and the actual need for separate security data boundaries.
Source: AZ-305 Study Guide.pdf, PDF page(s) 10; reference [I12]. Newly generated study item; human review pending.
Monitoring and logging
Workspace-context access can allow broad queries; supported resource-context access limits queries to data from accessible resources. Table controls can refine access, and table plans have limitations.
Source: AZ-305 Study Guide.pdf, PDF page(s) 10; reference [I13]. Newly generated study item; human review pending.
Monitoring and logging
For high-value operational or security data needing full analytics, supported alerts, and Insights. Interactive analytics retention can extend to two years.
Source: AZ-305 Study Guide.pdf, PDF page(s) 10-11; reference [I13]. Newly generated study item; human review pending.
Monitoring and logging
For mainly troubleshooting data with lower ingestion cost and query charges. Direct queries cover 30 days; Simple Log Alerts are supported, but Insights and resource-context queries are not.
Source: AZ-305 Study Guide.pdf, PDF page(s) 10-11; reference [I13]. Newly generated study item; human review pending.
Monitoring and logging
For large volumes of infrequently queried verbose or audit data. It emphasizes low ingestion cost, charges for queries, remains queryable through total retention, and has no direct alerts or Insights.
Source: AZ-305 Study Guide.pdf, PDF page(s) 11; reference [I13]. Newly generated study item; human review pending.
Monitoring and logging
No. Choose a plan per supported table so critical error data and verbose diagnostics can have different capabilities and economics.
Source: AZ-305 Study Guide.pdf, PDF page(s) 11; reference [I13]. Newly generated study item; human review pending.
Monitoring and logging
No. Current documentation supports full KQL with feature and context limitations. Summary rules still have plan-specific constraints; confirm requirements against the current plan.
Source: AZ-305 Study Guide.pdf, PDF page(s) 11; reference [I13]. Newly generated study item; human review pending.
Monitoring and logging
Analytics retention is the interactive monitoring period for Analytics data. Total retention includes long-term retention; current documented maxima are two years for Analytics retention and 12 years total.
Source: AZ-305 Study Guide.pdf, PDF page(s) 11; reference [I14]. Newly generated study item; human review pending.
Monitoring and logging
Use supported search scenarios such as asynchronous search jobs, which place results in an Analytics table for further investigation. Long retention does not imply immediate full-feature queries.
Source: AZ-305 Study Guide.pdf, PDF page(s) 11; reference [I14]. Newly generated study item; human review pending.
Monitoring and logging
Basic and Auxiliary queries and dashboard refreshes incur query scanning charges. Model ingestion, retention, scanning, exports, and query frequency together.
Source: AZ-305 Study Guide.pdf, PDF page(s) 11; reference [I13]. Newly generated study item; human review pending.
Monitoring and logging
A cap can stop collection during the noisy incident that most needs evidence. Prefer appropriate source selection and supported transformations while preserving essential telemetry.
Source: AZ-305 Study Guide.pdf, PDF page(s) 11; reference [I09]. Newly generated study item; human review pending.
Monitoring and logging
They maintain useful aggregates while raw data follows its appropriate plan and retention. Verify plan-specific query constraints and retain raw evidence where required.
Source: AZ-305 Study Guide.pdf, PDF page(s) 11; reference [I13]. Newly generated study item; human review pending.
Monitoring and logging
Standardized traces, metrics, and logs, connected with request and dependency information. Propagated correlation context enables investigation across multiple services.
Source: AZ-305 Study Guide.pdf, PDF page(s) 11; reference [I15]. Newly generated study item; human review pending.
Monitoring and logging
Sampling can reduce volume and cost but reduces forensic detail. Choose it deliberately according to diagnostic and audit requirements.
Source: AZ-305 Study Guide.pdf, PDF page(s) 11; reference [I15]. Newly generated study item; human review pending.
Monitoring and logging
Application Insights and workspace schemas can use different table and field names, such as requests/timestamp and AppRequests/TimeGenerated. Filter time early and use the actual schema.
Source: AZ-305 Study Guide.pdf, PDF page(s) 11-12; reference [I13]. Newly generated study item; human review pending.
Monitoring and logging
Container Insights sends supported container logs, events, and inventory to Log Analytics. Managed Prometheus metrics use an Azure Monitor workspace, which is a different resource.
Source: AZ-305 Study Guide.pdf, PDF page(s) 12; reference [I55]. Newly generated study item; human review pending.
Monitoring and logging
Metric alerts evaluate numeric signals and supported dynamic thresholds; log alerts evaluate queried records or aggregates; activity-log alerts detect supported management events.
Source: AZ-305 Study Guide.pdf, PDF page(s) 12; reference [I16]. Newly generated study item; human review pending.
Monitoring and logging
Define an owner, condition, severity, evaluation interval, threshold, dimensions, suppression, and response. Use reusable action groups for notifications or automation and test escalation.
Source: AZ-305 Study Guide.pdf, PDF page(s) 12; reference [I16]. Newly generated study item; human review pending.
Monitoring and logging
Service Health reports relevant provider issues, maintenance, and advisories; Azure Status gives the public global view; Resource Health describes individual resource health. They complement application telemetry.
Source: AZ-305 Study Guide.pdf, PDF page(s) 12; reference [I46]. Newly generated study item; human review pending.
Identity and access
Authentication proves an identity; authorization determines what it may do. A successful sign-in does not grant access to a blob, application, or database.
Source: AZ-305 Study Guide.pdf, PDF page(s) 13; reference [I49]. Newly generated study item; human review pending.
Identity and access
Entra ID provides cloud identity. AD DS provides traditional domain services such as LDAP, Kerberos, and domain join; Entra ID alone is not an LDAP or Kerberos domain endpoint.
Source: AZ-305 Study Guide.pdf, PDF page(s) 13; reference [I41]. Newly generated study item; human review pending.
Identity and access
Directory roles administer identity objects; Azure roles authorize operations on Azure resources. Global Administrator and subscription Owner are different assignments and are not interchangeable.
Source: AZ-305 Study Guide.pdf, PDF page(s) 13; reference [I21]. Newly generated study item; human review pending.
Identity and access
The registration defines the application's identity and configuration. A service principal represents that application within a tenant; managed identities are a special service-principal type.
Source: AZ-305 Study Guide.pdf, PDF page(s) 13; reference [I49]. Newly generated study item; human review pending.
Identity and access
OpenID Connect normally provides authentication and OAuth 2.0 access tokens authorize protected API access. Existing applications may require SAML or Windows authentication instead.
Source: AZ-305 Study Guide.pdf, PDF page(s) 13; reference [I49]. Newly generated study item; human review pending.
Identity and access
Synchronization provisions or updates directory objects. Authentication selects where credentials are validated, with different dependencies for PHS, PTA, and federation.
Source: AZ-305 Study Guide.pdf, PDF page(s) 13; reference [I43]. Newly generated study item; human review pending.
Identity and access
Cloud Sync uses lightweight on-premises provisioning agents and cloud-managed orchestration. Choose against current forest, attribute, device, writeback, and availability requirements.
Source: AZ-305 Study Guide.pdf, PDF page(s) 13; reference [I43]. Newly generated study item; human review pending.
Identity and access
Entra ID validates against a synchronized derived representation of the on-premises password hash. It does not require an on-premises validation request for each sign-in.
Source: AZ-305 Study Guide.pdf, PDF page(s) 13-14; reference [I17]. Newly generated study item; human review pending.
Identity and access
No. It synchronizes a derived representation, not plaintext or a reversibly stored password.
Source: AZ-305 Study Guide.pdf, PDF page(s) 14; reference [I17]. Newly generated study item; human review pending.
Identity and access
Existing synchronized users can continue cloud password authentication. New password and account changes cannot synchronize until the synchronization path recovers.
Source: AZ-305 Study Guide.pdf, PDF page(s) 14; reference [I17]. Newly generated study item; human review pending.
Identity and access
Cloud account state depends on synchronization timing, and some AD states behave differently. PHS does not validate current AD state directly at every cloud sign-in.
Source: AZ-305 Study Guide.pdf, PDF page(s) 14; reference [I17]. Newly generated study item; human review pending.
Identity and access
When on-premises AD account state, password policies, or sign-in hours must be checked at sign-in and reliable validation agents and domain controllers can be operated.
Source: AZ-305 Study Guide.pdf, PDF page(s) 13-14; reference [I17]. Newly generated study item; human review pending.
Identity and access
Agents need outbound service connectivity and domain-controller connectivity. Microsoft recommends three agents, but a site-wide domain-controller or network failure can still break validation.
Source: AZ-305 Study Guide.pdf, PDF page(s) 14; reference [I17]. Newly generated study item; human review pending.
Identity and access
No. PHS can be prepared as a backup, but switching authentication to it is a planned manual change requiring an operational recovery procedure.
Source: AZ-305 Study Guide.pdf, PDF page(s) 14; reference [I17]. Newly generated study item; human review pending.
Identity and access
When a defined requirement needs the external identity provider's capabilities and justifies its infrastructure, certificate, publishing, security, and maintenance dependencies.
Source: AZ-305 Study Guide.pdf, PDF page(s) 14; reference [I17]. Newly generated study item; human review pending.
Identity and access
It lets suitable user groups adopt cloud authentication incrementally while the transition is validated. Preconfigure and test emergency alternatives and dependency recovery.
Source: AZ-305 Study Guide.pdf, PDF page(s) 14; reference [I17]. Newly generated study item; human review pending.
Identity and access
It evaluates user/group, application, device, location, and risk signals and can block, require MFA, authentication strength, or device conditions for supported scenarios.
Source: AZ-305 Study Guide.pdf, PDF page(s) 14; reference [I37]. Newly generated study item; human review pending.
Identity and access
It is evaluated after first-factor authentication and applies access conditions. It does not replace the authentication method or grant application permissions.
Source: AZ-305 Study Guide.pdf, PDF page(s) 14; reference [I37]. Newly generated study item; human review pending.
Identity and access
Evaluate report-only results and roll out in stages where appropriate. Maintain tested emergency access so incorrect policies do not block recovery.
Source: AZ-305 Study Guide.pdf, PDF page(s) 14; reference [I37]. Newly generated study item; human review pending.
Identity and access
Authentication methods have different protection levels. Use appropriate authentication strength and recovery design for the risk; all MFA methods are not equally resistant to phishing.
Source: AZ-305 Study Guide.pdf, PDF page(s) 14; reference [I37]. Newly generated study item; human review pending.
Identity and access
For partners needing approved access to workforce resources, often with their existing identity provider. Guest authorization, cross-tenant assurance, and lifecycle still need governance.
Source: AZ-305 Study Guide.pdf, PDF page(s) 14-15; reference [I18]. Newly generated study item; human review pending.
Identity and access
For customer identity in a public application with an appropriate sign-up and sign-in experience separate from employee resources.
Source: AZ-305 Study Guide.pdf, PDF page(s) 14-15; reference [I18]. Newly generated study item; human review pending.
Identity and access
System-assigned identity is created with a supported resource and removed with it. User-assigned identity is a separate resource that can survive compute replacement and be attached where supported.
Source: AZ-305 Study Guide.pdf, PDF page(s) 15; reference [I19]. Newly generated study item; human review pending.
Identity and access
When permissions must exist before compute, identity continuity is required across replacement, or controlled reuse is needed. Shared identity also shares effective privileges.
Source: AZ-305 Study Guide.pdf, PDF page(s) 15; reference [I19]. Newly generated study item; human review pending.
Identity and access
It provides credential-free token acquisition. The target still requires a data role or database principal, the correct token audience, and working network and DNS access.
Source: AZ-305 Study Guide.pdf, PDF page(s) 15; reference [I19]. Newly generated study item; human review pending.
Identity and access
Entra trusts a configured external OpenID Connect token and exchanges a matching issuer, subject, and audience token for one usable by the workload's Entra identity.
Source: AZ-305 Study Guide.pdf, PDF page(s) 15; reference [I20]. Newly generated study item; human review pending.
Identity and access
Restrict the trusted issuer, subject, and audience and scope the target permissions. Federation removes a long-lived secret but does not justify broad trust or access.
Source: AZ-305 Study Guide.pdf, PDF page(s) 15; reference [I20]. Newly generated study item; human review pending.
Identity and access
A security principal, a role definition, and a scope. Applicable assignments inherit from parent scopes to descendants.
Source: AZ-305 Study Guide.pdf, PDF page(s) 15; reference [I21]. Newly generated study item; human review pending.
Identity and access
Owner manages resources and access; Contributor manages resources but lacks standard role-assignment permissions; Reader views management information. Service data access remains a separate concern.
Source: AZ-305 Study Guide.pdf, PDF page(s) 15; reference [I21]. Newly generated study item; human review pending.
Identity and access
Actions authorize supported management operations; DataActions authorize supported service data operations. Management Reader on a storage account does not grant blob reads.
Source: AZ-305 Study Guide.pdf, PDF page(s) 15-16; reference [I22]. Newly generated study item; human review pending.
Identity and access
Azure RBAC is additive across direct, group, and inherited assignments. Review the complete effective access set and remove the broader grant if necessary.
Source: AZ-305 Study Guide.pdf, PDF page(s) 16; reference [I21]. Newly generated study item; human review pending.
Identity and access
No. NotActions reduces the permissions granted by that role definition; another applicable role can still grant the excluded operation.
Source: AZ-305 Study Guide.pdf, PDF page(s) 16; reference [I21]. Newly generated study item; human review pending.
Identity and access
Some broad management roles can retrieve account keys or change access configuration. Evaluate these indirect escalation paths as well as explicit data roles.
Source: AZ-305 Study Guide.pdf, PDF page(s) 16; reference [I22]. Newly generated study item; human review pending.
Identity and access
Conditions can refine supported permissions using attributes, such as blob index tags. ABAC is not a universal condition language for every Azure operation.
Source: AZ-305 Study Guide.pdf, PDF page(s) 16; reference [I23]. Newly generated study item; human review pending.
Identity and access
The condition limits its own assignment. A broader unconditional assignment may still authorize the operation, so inspect all effective grants.
Source: AZ-305 Study Guide.pdf, PDF page(s) 16; reference [I23]. Newly generated study item; human review pending.
Identity and access
Preserve AD DS authentication, group/ACL authorization, DNS, domain-controller connectivity, and required device/domain configuration. Cloud sign-in alone does not grant file access.
Source: AZ-305 Study Guide.pdf, PDF page(s) 16; reference [I25]. Newly generated study item; human review pending.
Identity and access
For supported legacy Azure workloads needing managed domain join, Group Policy, LDAP, and Kerberos/NTLM without customer-managed domain controllers. It is not a full self-managed AD DS forest.
Source: AZ-305 Study Guide.pdf, PDF page(s) 16; reference [I25]. Newly generated study item; human review pending.
Identity and access
It publishes supported internal web applications to remote users through the cloud service and outbound-connected private network connectors, with Entra preauthentication where configured.
Source: AZ-305 Study Guide.pdf, PDF page(s) 16; reference [I24]. Newly generated study item; human review pending.
Identity and access
Correctly configured Kerberos constrained delegation lets the connector obtain a ticket for the permitted application SPN on behalf of the validated user. Identity mapping and app authorization still matter.
Source: AZ-305 Study Guide.pdf, PDF page(s) 16; reference [I39]. Newly generated study item; human review pending.
Identity and access
It supports SSO from supported Entra-joined or hybrid-joined devices to AD resources. On-premises domain controllers still issue service tickets and control authorization, and connectivity remains required.
Source: AZ-305 Study Guide.pdf, PDF page(s) 16; reference [I40]. Newly generated study item; human review pending.
Identity and access
Secrets hold retrievable sensitive values; keys support permitted cryptographic operations and CMKs; certificates manage X.509 objects with associated key/secret objects and supported renewal.
Source: AZ-305 Study Guide.pdf, PDF page(s) 16-17; reference [I26]. Newly generated study item; human review pending.
Identity and access
A dedicated single-tenant cryptographic-key service using FIPS 140-3 Level 3 validated HSMs. It does not store general secrets or manage certificate objects.
Source: AZ-305 Study Guide.pdf, PDF page(s) 17; reference [I28]. Newly generated study item; human review pending.
Identity and access
Premium vaults support HSM-protected keys alongside secrets and certificates. Managed HSM is a separate dedicated single-tenant key offering; validate integration, algorithms, isolation, and recovery.
Source: AZ-305 Study Guide.pdf, PDF page(s) 17; reference [I28]. Newly generated study item; human review pending.
Identity and access
It supports narrowly scoped vault data roles and improved separation. Legacy access policies can be changed through broad management permissions, so escalation paths need control.
Source: AZ-305 Study Guide.pdf, PDF page(s) 17; reference [I27]. Newly generated study item; human review pending.
Identity and access
New vaults created using that API version default to Azure RBAC. Existing access models and deployment settings still need to be reviewed explicitly.
Source: AZ-305 Study Guide.pdf, PDF page(s) 17; reference [I27]. Newly generated study item; human review pending.
Identity and access
Prefer a vault per application and environment, with appropriate groups and workload identities. Restrict network access where required and collect audits for denied operations and expiry.
Source: AZ-305 Study Guide.pdf, PDF page(s) 17; reference [I27]. Newly generated study item; human review pending.
Identity and access
Soft delete enables recovery within the retention period. Purge protection prevents permanent deletion before that period ends and cannot be overridden once enabled.
Source: AZ-305 Study Guide.pdf, PDF page(s) 17; reference [I44]. Newly generated study item; human review pending.
Identity and access
Losing a required encryption key can make otherwise intact encrypted data unusable. Protect recovery and retain key versions required by consumers and recovery operations.
Source: AZ-305 Study Guide.pdf, PDF page(s) 17; reference [I44]. Newly generated study item; human review pending.
Identity and access
Ensure consumers adopt new key versions, retain old versions still needed for decryption or recovery, and test transitions before disabling previous versions.
Source: AZ-305 Study Guide.pdf, PDF page(s) 17; reference [I45]. Newly generated study item; human review pending.
Identity and access
A secret workflow must update the external credential and refresh consumers; certificate renewal also requires consuming-service refresh. A vault version alone does not change an external password.
Source: AZ-305 Study Guide.pdf, PDF page(s) 17; reference [I50]. Newly generated study item; human review pending.
Governance and compliance
They apply common governance scopes above subscriptions so Azure policy and applicable access assignments inherit to descendants.
Source: AZ-305 Study Guide.pdf, PDF page(s) 18; reference [I31]. Newly generated study item; human review pending.
Governance and compliance
All subscriptions must trust the same Entra tenant. Each subscription has one parent management group, and each non-root management group has one parent.
Source: AZ-305 Study Guide.pdf, PDF page(s) 18; reference [I31]. Newly generated study item; human review pending.
Governance and compliance
It supports six management-group levels excluding the root and subscription levels. Keep the tree understandable and aligned to durable policy requirements.
Source: AZ-305 Study Guide.pdf, PDF page(s) 18; reference [I31]. Newly generated study item; human review pending.
Governance and compliance
Use durable governance needs such as platform, corporate-connected workloads, internet-facing workloads, or sandboxes. Reporting lines or geography alone need not define the tree.
Source: AZ-305 Study Guide.pdf, PDF page(s) 18; reference [I31]. Newly generated study item; human review pending.
Governance and compliance
Administrative ownership, billing, quotas, environment, scale, and regulatory needs can justify separation. Shared management groups provide common guardrails.
Source: AZ-305 Study Guide.pdf, PDF page(s) 18; reference [I31]. Newly generated study item; human review pending.
Governance and compliance
Assignments inherited from a common parent can reach multiple subscriptions. Restrict broad parent-scope access and use suitable role and scope boundaries.
Source: AZ-305 Study Guide.pdf, PDF page(s) 18; reference [I31]. Newly generated study item; human review pending.
Governance and compliance
Related lifecycle, ownership, and permissions. Keep a long-lived database separate from disposable resources when deletion or access needs differ.
Source: AZ-305 Study Guide.pdf, PDF page(s) 19; reference [I51]. Newly generated study item; human review pending.
Governance and compliance
An ordinary resource-group-scoped resource belongs to one group at a time; groups cannot nest. Groups can contain resources in multiple regions, independently of the metadata location.
Source: AZ-305 Study Guide.pdf, PDF page(s) 19; reference [I51]. Newly generated study item; human review pending.
Governance and compliance
Deletion initiates deletion of contained resources. Grouping by lifecycle helps prevent disposable deployments from deleting persistent dependencies.
Source: AZ-305 Study Guide.pdf, PDF page(s) 19; reference [I51]. Newly generated study item; human review pending.
Governance and compliance
Use consistent key-value metadata for owner group, environment, cost center, application, purpose, or classification. Tags support accountability, inventory, cost allocation, and automation.
Source: AZ-305 Study Guide.pdf, PDF page(s) 19; reference [I32]. Newly generated study item; human review pending.
Governance and compliance
No. Apply appropriate Azure Policy require/modify behavior to populate supported resources. Management groups do not support tags.
Source: AZ-305 Study Guide.pdf, PDF page(s) 19; reference [I32]. Newly generated study item; human review pending.
Governance and compliance
Secrets and personal data, because tags are plaintext and visible through reports, histories, and APIs. Prefer stable application identifiers and accountable owner groups.
Source: AZ-305 Study Guide.pdf, PDF page(s) 19; reference [I32]. Newly generated study item; human review pending.
Governance and compliance
Tag names are operationally case-insensitive and values are case-sensitive. Standardize both to prevent fragmented reports.
Source: AZ-305 Study Guide.pdf, PDF page(s) 19; reference [I32]. Newly generated study item; human review pending.
Governance and compliance
RBAC grants operations to identities; Policy evaluates and constrains supported resource configuration; tags provide metadata. A compliance tag is not evidence that a control is satisfied.
Source: AZ-305 Study Guide.pdf, PDF page(s) 19; reference [I29]. Newly generated study item; human review pending.
Governance and compliance
A definition expresses a rule; an initiative bundles related definitions; an assignment applies either to a scope with parameters, exclusions, and enforcement configuration.
Source: AZ-305 Study Guide.pdf, PDF page(s) 19; reference [I29]. Newly generated study item; human review pending.
Governance and compliance
It records noncompliance without blocking or repairing the operation. Use it to understand exposure and rollout impact.
Source: AZ-305 Study Guide.pdf, PDF page(s) 19; reference [I29]. Newly generated study item; human review pending.
Governance and compliance
It rejects operations violating applicable evaluated policy. It does not repair existing noncompliant resources.
Source: AZ-305 Study Guide.pdf, PDF page(s) 19-20; reference [I29]. Newly generated study item; human review pending.
Governance and compliance
When compliance depends on a required related resource or configuration that may be missing or noncompliant. It reports the finding without deploying the related configuration.
Source: AZ-305 Study Guide.pdf, PDF page(s) 19; reference [I29]. Newly generated study item; human review pending.
Governance and compliance
To deploy supported related configuration, such as diagnostic settings, when its conditions and timing allow. Existing resources need appropriate remediation tasks.
Source: AZ-305 Study Guide.pdf, PDF page(s) 19-20; reference [I30]. Newly generated study item; human review pending.
Governance and compliance
For supported property changes or added values, such as standardized tags. An assignment identity with required permissions and a remediation task may be needed for existing resources.
Source: AZ-305 Study Guide.pdf, PDF page(s) 19-20; reference [I30]. Newly generated study item; human review pending.
Governance and compliance
Use a supported modify or DeployIfNotExists definition, an assignment managed identity with required roles, and a remediation task. A compliance scan alone does not perform repair.
Source: AZ-305 Study Guide.pdf, PDF page(s) 20; reference [I30]. Newly generated study item; human review pending.
Governance and compliance
Changing a definition does not automatically update the assignment identity's permissions. Confirm role requirements and test that remediation can perform the new actions.
Source: AZ-305 Study Guide.pdf, PDF page(s) 20; reference [I30]. Newly generated study item; human review pending.
Governance and compliance
Assess with audit and compliance reports, fix templates and existing resources, then enforce restrictions. Document exceptions with owners, justification, expiry, and ongoing review.
Source: AZ-305 Study Guide.pdf, PDF page(s) 20; reference [I29]. Newly generated study item; human review pending.
Governance and compliance
An exclusion removes a scope from evaluation. An exemption records an accepted exception against an assignment and can preserve governance context, with accountable ownership and expiry.
Source: AZ-305 Study Guide.pdf, PDF page(s) 20; reference [I52]. Newly generated study item; human review pending.
Governance and compliance
For supported configuration compliance inside a guest OS, such as security baselines. Validate guest extension, identity, package, assignment mode, or Arc prerequisites.
Source: AZ-305 Study Guide.pdf, PDF page(s) 20; reference [I56]. Newly generated study item; human review pending.
Governance and compliance
Defender for Cloud assesses security posture and supported workload threats; Sentinel correlates security events and supports incidents and response; Azure Monitor provides operational observability.
Source: AZ-305 Study Guide.pdf, PDF page(s) 20; reference [I36]. Newly generated study item; human review pending.
Governance and compliance
No. It shows assessed technical controls. Legal or regulatory obligations also need procedures, accountable owners, and the required audit evidence.
Source: AZ-305 Study Guide.pdf, PDF page(s) 20; reference [I36]. Newly generated study item; human review pending.
Governance and compliance
Use current infrastructure as code, deployment stacks for lifecycle/governance needs, and template specs for versioned reusable templates. Blueprints is in phased retirement as of October 20, 2026.
Source: AZ-305 Study Guide.pdf, PDF page(s) 20; reference [I35]. Newly generated study item; human review pending.
Governance and compliance
New definitions/versions stopped July 31, 2026; definition changes/new assignments stop October 31; assignment changes stop December 31; final retirement is January 31, 2027.
Source: AZ-305 Study Guide.pdf, PDF page(s) 20; reference [I35]. Newly generated study item; human review pending.
Governance and compliance
Previously deployed workload resources remain. Unexported blueprint definitions, versions, and assignments are deleted and blueprint lock enforcement ends, so migrate governance and protection.
Source: AZ-305 Study Guide.pdf, PDF page(s) 20; reference [I35]. Newly generated study item; human review pending.
Governance and compliance
Synchronization aligns directories; provisioning manages supported application accounts and assignments; governance decides whether access should exist and how its lifecycle is controlled.
Source: AZ-305 Study Guide.pdf, PDF page(s) 20-21; reference [I33]. Newly generated study item; human review pending.
Governance and compliance
Eligibility permits activation when needed; active assignment grants the role's permissions for its active duration. Activation can require approval, MFA, justification, and expiry where configured.
Source: AZ-305 Study Guide.pdf, PDF page(s) 21; reference [I34]. Newly generated study item; human review pending.
Governance and compliance
Choose a narrow role and scope, review eligibility and activations, keep emergency access, and ensure incident approvers are available. PIM limits duration but not permissions while active.
Source: AZ-305 Study Guide.pdf, PDF page(s) 21; reference [I34]. Newly generated study item; human review pending.
Governance and compliance
Approved, expiring bundles of supported group, team, application, and SharePoint access through access packages with request policies, approvals, and reviews. Group membership can provide indirect Azure access.
Source: AZ-305 Study Guide.pdf, PDF page(s) 21; reference [I33]. Newly generated study item; human review pending.
Governance and compliance
Reviews need scope, recurrence, reviewers, fallback, and applied decisions; check alternate effective grants. Workflows need reliable identity attributes and lifecycle triggers. Verify feature-specific Governance, Suite, or P2 licensing.
Source: AZ-305 Study Guide.pdf, PDF page(s) 21; reference [I33]. Newly generated study item; human review pending.
Relational data
Atomicity: all operations commit together. Consistency: database rules hold. Isolation: concurrent transactions are controlled. Durability: a committed write survives.
Source: validated AZ-305 Study Guide, PDF page 22; reference D01. Original learning item; review required.
Relational data
Required engine/version/extensions, instance features, operating-system access, latency, transaction demand, growth, licensing, and recovery objectives.
Source: validated AZ-305 Study Guide, PDF page 22-23; reference D01. Original learning item; review required.
Relational data
A database-focused SQL Server-compatible workload whose required features fit the managed database model and do not require operating-system control.
Source: validated AZ-305 Study Guide, PDF page 22-23; reference D01. Original learning item; review required.
Relational data
High SQL Server instance compatibility, supported cross-database queries, and SQL Agent jobs; assess actual compatibility because it is not unlimited.
Source: validated AZ-305 Study Guide, PDF page 22-23; reference D01. Original learning item; review required.
Relational data
When the application needs operating-system access, a specific engine version, full deployment control, or features unsupported by SQL PaaS.
Source: validated AZ-305 Study Guide, PDF page 22-23; reference D01. Original learning item; review required.
Relational data
Guest OS, SQL engine, patch policy, storage, security, backups, and the HA topology; Azure tooling assists rather than removes these duties.
Source: validated AZ-305 Study Guide, PDF page 22; reference D01. Original learning item; review required.
Relational data
Schema, permissions, query performance, connectivity, retention configuration, and testing application recovery.
Source: validated AZ-305 Study Guide, PDF page 22; reference D01. Original learning item; review required.
Relational data
It preserves the required PostgreSQL engine and supported extensions with managed operations; an SQL Server service is not engine-compatible merely because both use SQL.
Source: validated AZ-305 Study Guide, PDF page 23; reference D11. Original learning item; review required.
Relational data
Purchasing model expresses/bills resources; service tier defines architecture and capabilities; compute tier determines provisioned versus automatically scaled compute.
Source: validated AZ-305 Study Guide, PDF page 23; reference D02. Original learning item; review required.
Relational data
A database transaction unit bundles relative CPU, memory, and I/O. The DTU tiers are Basic, Standard, and Premium.
Source: validated AZ-305 Study Guide, PDF page 23; reference D54. Original learning item; review required.
Relational data
Compute cores and clearer separation of compute, storage, and backup costs. SQL Database tiers include General Purpose, Business Critical, and Hyperscale.
Source: validated AZ-305 Study Guide, PDF page 23; reference D02. Original learning item; review required.
Relational data
Separated compute and remote durable storage, suited to many ordinary transactional workloads with balanced price and performance.
Source: validated AZ-305 Study Guide, PDF page 23; reference D02. Original learning item; review required.
Relational data
Local SSD storage and multiple replicas for low storage latency and high I/O; eligible read-only replicas can offload reads at higher cost.
Source: validated AZ-305 Study Guide, PDF page 23; reference D02. Original learning item; review required.
Relational data
Distributed page-server/log-service storage decoupled from compute, supporting large growth and read replicas; documented maximum can reach 128 TB in supported configurations.
Source: validated AZ-305 Study Guide, PDF page 23; reference D02. Original learning item; review required.
Relational data
Supported offerings include serverless or provisioned single databases and Hyperscale elastic pools; verify each configuration's feature matrix.
Source: validated AZ-305 Study Guide, PDF page 23; reference D02. Original learning item; review required.
Relational data
Its vCore General Purpose and Business Critical tiers, including the documented Next-gen General Purpose option. Do not assume SQL Database Hyperscale exists for Managed Instance.
Source: validated AZ-305 Study Guide, PDF page 23; reference D55. Original learning item; review required.
Relational data
Sustained demand and predictable capacity where allocated compute remains useful over time.
Source: validated AZ-305 Study Guide, PDF page 23; reference D03. Original learning item; review required.
Relational data
Compute within configured minimum and maximum vCores. It does not fix poor queries, unlimited storage growth, or an insufficient maximum.
Source: validated AZ-305 Study Guide, PDF page 23; reference D03. Original learning item; review required.
Relational data
Storage stays billed, a high compute minimum and continuous activity sustain charges, and frequent resumes can reduce savings.
Source: validated AZ-305 Study Guide, PDF page 23-24; reference D03. Original learning item; review required.
Relational data
Autoscaling changes compute while online; eligible idle databases can separately pause and later resume, introducing latency and feature restrictions.
Source: validated AZ-305 Study Guide, PDF page 24; reference D04. Original learning item; review required.
Relational data
Open sessions, active geo-replication or failover groups, and long-term backup retention can keep a database online even with little useful workload.
Source: validated AZ-305 Study Guide, PDF page 24; reference D04. Original learning item; review required.
Relational data
Preview. Designs requiring mature generally available behavior should not depend on it; General Purpose serverless supports auto-pause.
Source: validated AZ-305 Study Guide, PDF page 24; reference D04. Original learning item; review required.
Relational data
CPU, data/log I/O, memory pressure, locks, and query plans. Correct the actual bottleneck before increasing resources.
Source: validated AZ-305 Study Guide, PDF page 24; reference D01. Original learning item; review required.
Relational data
Lock contention or inefficient queries can remain dominant. Indexes, reduced scanning, shorter transactions, and query tuning may address the cause.
Source: validated AZ-305 Study Guide, PDF page 24; reference D01. Original learning item; review required.
Relational data
A shared resource budget for multiple separate SQL databases, constrained by pool and per-database limits. It preserves database separation.
Source: validated AZ-305 Study Guide, PDF page 24; reference D05. Original learning item; review required.
Relational data
When tenant databases have differing peak times, allowing quiet databases' spare capacity to support busy databases.
Source: validated AZ-305 Study Guide, PDF page 24; reference D05. Original learning item; review required.
Relational data
The pool must cover overlapping demand; it cannot guarantee that every database reaches its individual maximum simultaneously.
Source: validated AZ-305 Study Guide, PDF page 24; reference D05. Original learning item; review required.
Relational data
It offloads eligible read-only work using supported replica routing. It does not increase the primary's write capacity.
Source: validated AZ-305 Study Guide, PDF page 24; reference D06. Original learning item; review required.
Relational data
Partitioning/sharding records across databases with an access-aligned shard key, accepting more complex cross-shard queries and transactions.
Source: validated AZ-305 Study Guide, PDF page 24; reference D01. Original learning item; review required.
Relational data
Database files, logs, and backups at rest. It does not prevent an authorized SELECT or replace TLS, access controls, or retention.
Source: validated AZ-305 Study Guide, PDF page 24; reference D09. Original learning item; review required.
Relational data
The database must retain permission and access to required key versions in Key Vault or an eligible managed HSM; plan rotation and key recovery.
Source: validated AZ-305 Study Guide, PDF page 24; reference D09. Original learning item; review required.
Relational data
Entra/managed identity establishes the principal; database roles and permissions determine allowed data operations. ARM management rights do not confer all data permissions.
Source: validated AZ-305 Study Guide, PDF page 24; reference D10. Original learning item; review required.
Relational data
Authentication, data permissions, correct DNS, and a usable route from the client. Private connectivity limits exposure but does not authorize queries.
Source: validated AZ-305 Study Guide, PDF page 24; reference D10. Original learning item; review required.
Relational data
Always Encrypted protects values client-side with separately managed keys; assess supported operations and enclave requirements.
Source: validated AZ-305 Study Guide, PDF page 25; reference D01. Original learning item; review required.
Relational data
Masking changes displayed values for selected users and is not encryption. Row-level security filters rows using authorization predicates.
Source: validated AZ-305 Study Guide, PDF page 25; reference D01. Original learning item; review required.
Relational data
Default PITR retention is seven days; ordinary configuration is one to thirty-five days, Basic one to seven. LTR can retain selected backups up to ten years.
Source: validated AZ-305 Study Guide, PDF page 25; reference D08. Original learning item; review required.
Relational data
Deletion/corruption can replicate. Geographic replication maintains a current copy; retained backups preserve earlier good states.
Source: validated AZ-305 Study Guide, PDF page 25; reference D06. Original learning item; review required.
Relational data
Read replicas asynchronously offload reads. Supported HA uses a synchronous availability standby, which is not the normal reporting endpoint.
Source: validated AZ-305 Study Guide, PDF page 25; reference D46. Original learning item; review required.
Object, file, and NoSQL data
Semi-structured records have flexible fields, such as varying JSON documents. Unstructured objects include images, video, and binary files not normally queried as database columns.
Source: validated AZ-305 Study Guide, PDF page 26; reference D59. Original learning item; review required.
Object, file, and NoSQL data
Object storage exposes objects via APIs; file storage exposes directories and shared file protocols; block storage exposes disks to an OS.
Source: validated AZ-305 Study Guide, PDF page 26; reference D20. Original learning item; review required.
Object, file, and NoSQL data
Azure Blob Storage, with appropriate object security, access tiers, lifecycle, and recovery controls.
Source: validated AZ-305 Study Guide, PDF page 26; reference D20. Original learning item; review required.
Object, file, and NoSQL data
Azure Files in a compatible configuration; Blob object APIs do not transparently satisfy shared filesystem semantics.
Source: validated AZ-305 Study Guide, PDF page 26; reference D24. Original learning item; review required.
Object, file, and NoSQL data
Azure managed disks, sized for IOPS/throughput/latency and constrained by supported region and VM limits.
Source: validated AZ-305 Study Guide, PDF page 26-27; reference D50. Original learning item; review required.
Object, file, and NoSQL data
Simple low-cost key-and-attribute entities using PartitionKey and RowKey, when its indexing and query model satisfy the application.
Source: validated AZ-305 Study Guide, PDF page 26; reference D51. Original learning item; review required.
Object, file, and NoSQL data
Block blobs.
Source: validated AZ-305 Study Guide, PDF page 26; reference D20. Original learning item; review required.
Object, file, and NoSQL data
Append blobs suit supported append-oriented patterns. Page blobs provide random read/write access to ranges.
Source: validated AZ-305 Study Guide, PDF page 26; reference D20. Original learning item; review required.
Object, file, and NoSQL data
They resemble folders in naming, but flat namespace operations and permissions differ from first-class hierarchical directories.
Source: validated AZ-305 Study Guide, PDF page 26-27; reference D19. Original learning item; review required.
Object, file, and NoSQL data
IOPS, throughput, capacity, file count, and transaction patterns, along with supported protocol, identity, redundancy, and backup behavior.
Source: validated AZ-305 Study Guide, PDF page 26; reference D24. Original learning item; review required.
Object, file, and NoSQL data
It synchronizes supported Windows Server endpoints with an Azure Files cloud share while retaining hot files locally and tiering cold files.
Source: validated AZ-305 Study Guide, PDF page 26-27; reference D25. Original learning item; review required.
Object, file, and NoSQL data
It synchronizes changes, including potentially destructive changes; independent historical recovery points protect earlier good states.
Source: validated AZ-305 Study Guide, PDF page 27; reference D25. Original learning item; review required.
Object, file, and NoSQL data
The VM's own I/O limits can remain the bottleneck even when its disk supports higher performance.
Source: validated AZ-305 Study Guide, PDF page 27; reference D50. Original learning item; review required.
Object, file, and NoSQL data
Temporary disks or ephemeral OS disks; use durable storage and appropriate recovery controls.
Source: validated AZ-305 Study Guide, PDF page 27; reference D50. Original learning item; review required.
Object, file, and NoSQL data
Blob-based storage with first-class directories, efficient directory operations, and POSIX-style path ACLs for analytics workloads.
Source: validated AZ-305 Study Guide, PDF page 27; reference D19. Original learning item; review required.
Object, file, and NoSQL data
Renaming a directory can be efficient instead of rewriting potentially millions of object names after processing temporary output.
Source: validated AZ-305 Study Guide, PDF page 27; reference D19. Original learning item; review required.
Object, file, and NoSQL data
The lake stores files; Synapse, Databricks, Fabric, or another engine processes and analyzes them.
Source: validated AZ-305 Study Guide, PDF page 27; reference D19. Original learning item; review required.
Object, file, and NoSQL data
Check every needed Blob capability and recovery feature; ordinary block-blob PITR does not support hierarchical namespace accounts.
Source: validated AZ-305 Study Guide, PDF page 27; reference D21. Original learning item; review required.
Object, file, and NoSQL data
No. Roles and role conditions are evaluated first; an ACL cannot narrow already sufficient role-granted access.
Source: validated AZ-305 Study Guide, PDF page 27; reference D22. Original learning item; review required.
Object, file, and NoSQL data
Necessary execute permissions along the path, combined with suitable data-role/ACL authorization for the intended file operation.
Source: validated AZ-305 Study Guide, PDF page 27; reference D22. Original learning item; review required.
Object, file, and NoSQL data
Hot, cool, and cold are online. Archive is offline and requires rehydration before normal access.
Source: validated AZ-305 Study Guide, PDF page 27-28; reference D18. Original learning item; review required.
Object, file, and NoSQL data
Cool thirty days, cold ninety days, archive 180 days in the stated general-purpose-v2 context; these are billing rules, not deletion bans.
Source: validated AZ-305 Study Guide, PDF page 27-28; reference D18. Original learning item; review required.
Object, file, and NoSQL data
Retrieval, transaction, early-deletion, and rehydration charges can dominate for frequently read or short-lived objects.
Source: validated AZ-305 Study Guide, PDF page 27-28; reference D18. Original learning item; review required.
Object, file, and NoSQL data
Rehydrate it to an online tier; priority, object size, and service conditions affect completion.
Source: validated AZ-305 Study Guide, PDF page 28; reference D18. Original learning item; review required.
Object, file, and NoSQL data
LRS, GRS, and RA-GRS. ZRS, GZRS, and RA-GZRS do not support archive.
Source: validated AZ-305 Study Guide, PDF page 28; reference D18. Original learning item; review required.
Object, file, and NoSQL data
Asynchronously tiers/deletes eligible objects using age and supported filters/properties; it requires explicit business retention rules.
Source: validated AZ-305 Study Guide, PDF page 28; reference D49. Original learning item; review required.
Object, file, and NoSQL data
They have different recovery and retention purposes; indiscriminate deletion can remove required recovery history.
Source: validated AZ-305 Study Guide, PDF page 28; reference D49. Original learning item; review required.
Object, file, and NoSQL data
An applicable immutable retention policy or legal hold; automatic lifecycle actions must obey protection requirements.
Source: validated AZ-305 Study Guide, PDF page 28; reference D26. Original learning item; review required.
Object, file, and NoSQL data
Durability concerns data survival; availability concerns current request access. Durable copies may still be inaccessible during an outage.
Source: validated AZ-305 Study Guide, PDF page 28; reference D17. Original learning item; review required.
Object, file, and NoSQL data
Multiple synchronous copies within one physical datacenter, protecting local hardware failures without a separate zone or geographic copy.
Source: validated AZ-305 Study Guide, PDF page 28; reference D17. Original learning item; review required.
Object, file, and NoSQL data
Synchronous copies across supported availability zones in the primary region, protecting a zone failure; it adds no geographic copy.
Source: validated AZ-305 Study Guide, PDF page 28; reference D17. Original learning item; review required.
Object, file, and NoSQL data
LRS in the primary plus asynchronous replication to LRS in a secondary region; secondary access normally requires failover.
Source: validated AZ-305 Study Guide, PDF page 29; reference D17. Original learning item; review required.
Object, file, and NoSQL data
ZRS in the primary plus asynchronous geographic replication to locally redundant copies in the secondary.
Source: validated AZ-305 Study Guide, PDF page 29; reference D17. Original learning item; review required.
Object, file, and NoSQL data
Supported secondary-region read access before failover. The secondary may lag and is not a second normal writable primary.
Source: validated AZ-305 Study Guide, PDF page 29; reference D17. Original learning item; review required.
Object, file, and NoSQL data
Services within a storage account share its redundancy setting; incompatible requirements need separate accounts.
Source: validated AZ-305 Study Guide, PDF page 29; reference D17. Original learning item; review required.
Object, file, and NoSQL data
Which writes reached the geographic secondary before failover and the potential data gap, rather than a universal zero-loss guarantee.
Source: validated AZ-305 Study Guide, PDF page 29; reference D17. Original learning item; review required.
Object, file, and NoSQL data
Azure Files has different supported access/failover semantics; readable secondaries for other services do not create a secondary Files share endpoint.
Source: validated AZ-305 Study Guide, PDF page 29; reference D25. Original learning item; review required.
Object, file, and NoSQL data
They do not support GRS or GZRS; use a different compatible regional recovery design.
Source: validated AZ-305 Study Guide, PDF page 29; reference D25. Original learning item; review required.
Object, file, and NoSQL data
For eligible opt-in workloads, block-blob Last Sync Time lag of fifteen minutes or less for 99% of the billing month, subject to documented exclusions.
Source: validated AZ-305 Study Guide, PDF page 29; reference D68. Original learning item; review required.
Object, file, and NoSQL data
It remains asynchronous, requires eligibility/enablement, has exclusions, and its specific block-blob SLA does not extend universally to Azure Files.
Source: validated AZ-305 Study Guide, PDF page 29; reference D68. Original learning item; review required.
Object, file, and NoSQL data
Data at rest using Microsoft-managed or eligible customer-managed keys; valid authorized readers can still receive plaintext.
Source: validated AZ-305 Study Guide, PDF page 29; reference D60. Original learning item; review required.
Object, file, and NoSQL data
A bearer token delegating limited supported storage operations/resources over a defined interval, with available request restrictions.
Source: validated AZ-305 Study Guide, PDF page 29; reference D23. Original learning item; review required.
Object, file, and NoSQL data
Blob user delegation SAS uses a key obtained with Entra credentials. Service/account SAS use an account key.
Source: validated AZ-305 Study Guide, PDF page 29; reference D23. Original learning item; review required.
Object, file, and NoSQL data
Least necessary permissions/resources, short lifetime, suitable protocol restrictions, secure handling, and a revocation plan.
Source: validated AZ-305 Study Guide, PDF page 29; reference D23. Original learning item; review required.
Object, file, and NoSQL data
No. It controls eligible service SAS tokens; it is not a universal revocation mechanism for account or user delegation SAS.
Source: validated AZ-305 Study Guide, PDF page 29; reference D23. Original learning item; review required.
Object, file, and NoSQL data
Blob soft delete retains deleted objects for a period; container soft delete protects against container deletion.
Source: validated AZ-305 Study Guide, PDF page 29; reference D20. Original learning item; review required.
Object, file, and NoSQL data
Soft delete, versioning, and change feed. It does not protect against deleting the whole storage account.
Source: validated AZ-305 Study Guide, PDF page 29; reference D21. Original learning item; review required.
Object, file, and NoSQL data
It protects deleted files/directories but does not offer equivalent overwrite recovery; choose compatible independent protection.
Source: validated AZ-305 Study Guide, PDF page 29; reference D20. Original learning item; review required.
Object, file, and NoSQL data
Eligible WORM retention via time-based policies or legal holds, resisting modification/deletion during the protected period.
Source: validated AZ-305 Study Guide, PDF page 29-30; reference D26. Original learning item; review required.
Object, file, and NoSQL data
A locked time-based policy cannot casually be shortened and can block legitimate overwrites or deletion; verify scope and write behavior first.
Source: validated AZ-305 Study Guide, PDF page 30; reference D26. Original learning item; review required.
Object, file, and NoSQL data
Records sharing the same full partition-key value. Azure maps logical partitions to managed physical partitions and replica sets.
Source: validated AZ-305 Study Guide, PDF page 30; reference D13. Original learning item; review required.
Object, file, and NoSQL data
High enough cardinality and balanced storage/traffic distribution, aligned with frequent query access patterns.
Source: validated AZ-305 Study Guide, PDF page 30; reference D13. Original learning item; review required.
Object, file, and NoSQL data
Low cardinality or concentrated demand puts most requests into a few key values despite available account-wide throughput.
Source: validated AZ-305 Study Guide, PDF page 30; reference D13. Original learning item; review required.
Object, file, and NoSQL data
Balanced writes but inefficient business queries that must scan across partitions.
Source: validated AZ-305 Study Guide, PDF page 30; reference D13. Original learning item; review required.
Object, file, and NoSQL data
20 GB; its throughput is also bounded by a physical partition. Hierarchical keys can spread tenant prefixes across lower-level values.
Source: validated AZ-305 Study Guide, PDF page 30; reference D13. Original learning item; review required.
Object, file, and NoSQL data
One logical partition. Partition choice affects atomic business operations as well as query efficiency.
Source: validated AZ-305 Study Guide, PDF page 30; reference D13. Original learning item; review required.
Object, file, and NoSQL data
RU charge is the normalized cost of one request; RU/s is the throughput budget each second. Measure representative operations for sizing.
Source: validated AZ-305 Study Guide, PDF page 30; reference D15. Original learning item; review required.
Object, file, and NoSQL data
Manual provisioned throughput for steady use; autoscale provisioned throughput for fluctuating demand; serverless consumed-RU billing for appropriate intermittent single-region use.
Source: validated AZ-305 Study Guide, PDF page 30-31; reference D14. Original learning item; review required.
Object, file, and NoSQL data
Strong: latest committed value. Bounded staleness: bounded versions/time lag. Session: session guarantees including read-your-writes. Consistent prefix: write order. Eventual: convergence without fixed freshness.
Source: validated AZ-305 Study Guide, PDF page 31; reference D12. Original learning item; review required.
Object, file, and NoSQL data
Strong consistency is unsupported; serverless is single-region. Concurrent updates need supported conflict handling, and last-write-wins can discard a business update.
Source: validated AZ-305 Study Guide, PDF page 31; reference D16. Original learning item; review required.
Integration and analytics
Extraction, movement, cleansing, transformation, orchestration, and monitoring combine source data into usable forms.
Source: validated AZ-305 Study Guide, PDF page 32; reference D47. Original learning item; review required.
Integration and analytics
Integration prepares/combines data; analysis queries, aggregates, models, and reports on prepared data.
Source: validated AZ-305 Study Guide, PDF page 32; reference D47. Original learning item; review required.
Integration and analytics
Storage/ingestion alone does not define transformations, quality, orchestration, serving models, or reporting freshness.
Source: validated AZ-305 Study Guide, PDF page 32; reference D19. Original learning item; review required.
Integration and analytics
OLTP performs many short transactional operations enforcing application rules; OLAP scans/aggregates large historical datasets for analysis.
Source: validated AZ-305 Study Guide, PDF page 32; reference D28. Original learning item; review required.
Integration and analytics
Independent analytical capacity and data layout reduce interference with customer transactions and support historical retention.
Source: validated AZ-305 Study Guide, PDF page 32; reference D28. Original learning item; review required.
Integration and analytics
Required end-to-end data/report freshness, alongside correctness, cost, replay, and source capabilities.
Source: validated AZ-305 Study Guide, PDF page 32; reference D48. Original learning item; review required.
Integration and analytics
Extract, transform, load: transformations precede arrival at the final destination; useful for excluding sensitive/irrelevant fields early.
Source: validated AZ-305 Study Guide, PDF page 32; reference D47. Original learning item; review required.
Integration and analytics
Extract, load, transform: raw source detail lands before transformation by a destination/associated scalable engine, supporting later reprocessing.
Source: validated AZ-305 Study Guide, PDF page 32; reference D47. Original learning item; review required.
Integration and analytics
Full load copies everything; incremental load copies changes since a tracked point, reducing time/traffic when correctly implemented.
Source: validated AZ-305 Study Guide, PDF page 32; reference D47. Original learning item; review required.
Integration and analytics
Equal timestamps, late updates, time-zone boundaries, and deletion records; use robust boundaries/change tracking and reconciliation.
Source: validated AZ-305 Study Guide, PDF page 32; reference D47. Original learning item; review required.
Integration and analytics
Supported source change events for inserts, updates, and deletes, instead of inferring every change from a timestamp.
Source: validated AZ-305 Study Guide, PDF page 32; reference D47. Original learning item; review required.
Integration and analytics
They record processed progress so recovery can resume/replay from a known location; safe replay still requires correct sink semantics.
Source: validated AZ-305 Study Guide, PDF page 32; reference D47. Original learning item; review required.
Integration and analytics
Rerunning the same input produces the same intended business result rather than duplicate orders or repeated side effects.
Source: validated AZ-305 Study Guide, PDF page 32; reference D47. Original learning item; review required.
Integration and analytics
Reconcile row counts, business totals, expected changes, and quality boundaries to establish that the resulting data is correct.
Source: validated AZ-305 Study Guide, PDF page 32; reference D47. Original learning item; review required.
Integration and analytics
Raw preserves source data; refined standardizes/cleans records; curated exposes business-ready tables/aggregates. Often called bronze, silver, gold.
Source: validated AZ-305 Study Guide, PDF page 33; reference D29. Original learning item; review required.
Integration and analytics
It enables controlled reprocessing after a logic defect without recollecting every original source record.
Source: validated AZ-305 Study Guide, PDF page 33; reference D29. Original learning item; review required.
Integration and analytics
Every layer plus quarantine records and temporary output; moving/cleansing data does not remove security duties.
Source: validated AZ-305 Study Guide, PDF page 33; reference D29. Original learning item; review required.
Integration and analytics
Pipeline: activities/workflow. Linked service: connection. Dataset: referenced data. Trigger: schedule/supported event starting execution.
Source: validated AZ-305 Study Guide, PDF page 33; reference D47. Original learning item; review required.
Integration and analytics
Moves data through supported connectors. Transformations can use mapping data flows or be dispatched to other engines.
Source: validated AZ-305 Study Guide, PDF page 33; reference D47. Original learning item; review required.
Integration and analytics
Managed cloud execution/connectivity for supported data movement and transformation capabilities.
Source: validated AZ-305 Study Guide, PDF page 33; reference D27. Original learning item; review required.
Integration and analytics
To reach supported on-premises/private sources unavailable directly to managed execution; deploy, protect, and monitor supported nodes.
Source: validated AZ-305 Study Guide, PDF page 33; reference D27. Original learning item; review required.
Integration and analytics
Running supported existing SQL Server Integration Services packages in Azure.
Source: validated AZ-305 Study Guide, PDF page 33; reference D27. Original learning item; review required.
Integration and analytics
Authentication does not create routes, firewall permissions, DNS, or network reachability; runtime placement must meet these requirements.
Source: validated AZ-305 Study Guide, PDF page 33; reference D27. Original learning item; review required.
Integration and analytics
Use multiple supported nodes with protected credentials and monitoring, while testing source/destination throughput and connectivity.
Source: validated AZ-305 Study Guide, PDF page 33; reference D27. Original learning item; review required.
Integration and analytics
Dedicated pools allocate distributed warehouse capacity; serverless SQL queries eligible lake files with data-scanning cost and different feature limits.
Source: validated AZ-305 Study Guide, PDF page 33-34; reference D28. Original learning item; review required.
Integration and analytics
Partition files by common filters and use suitable columnar formats, reducing eligible data read by queries.
Source: validated AZ-305 Study Guide, PDF page 34; reference D28. Original learning item; review required.
Integration and analytics
Databricks: Spark engineering/streaming/lakehouse/data science. Fabric: integrated OneLake/SaaS/reporting platform. ADX: interactive telemetry/log/time-series exploration using KQL.
Source: validated AZ-305 Study Guide, PDF page 33-34; reference D29. Original learning item; review required.
Integration and analytics
Event versus processing time, windows, late-arrival/ordering policy, checkpoints, duplicate handling, and replayable input.
Source: validated AZ-305 Study Guide, PDF page 34; reference D48. Original learning item; review required.
Integration and analytics
Tumbling windows partition time into non-overlapping intervals; sliding windows evaluate a moving interval.
Source: validated AZ-305 Study Guide, PDF page 34; reference D48. Original learning item; review required.
Integration and analytics
Discovery, classification, cataloging, and lineage; it does not automatically grant underlying data access or execute transformations.
Source: validated AZ-305 Study Guide, PDF page 34; reference D32. Original learning item; review required.
Backup and disaster recovery
Maximum acceptable loss of recent data as a time interval backward from an incident; define it for the workload and failure scenario.
Source: validated AZ-305 Study Guide, PDF page 36; reference D58. Original learning item; review required.
Backup and disaster recovery
Target elapsed time to restore required business service after disruption, including detection, dependencies, validation, and routing.
Source: validated AZ-305 Study Guide, PDF page 36; reference D58. Original learning item; review required.
Backup and disaster recovery
Five-minute data gap and thirty-minute recovery duration.
Source: validated AZ-305 Study Guide, PDF page 36; reference D58. Original learning item; review required.
Backup and disaster recovery
An incident just before the next backup can lose almost an hour; use a mechanism whose usable recovery points and operations meet the objective.
Source: validated AZ-305 Study Guide, PDF page 36; reference D58. Original learning item; review required.
Backup and disaster recovery
Identity, networks, DNS, databases, secrets, startup ordering, capacity, validation, and traffic routing also contribute to user recovery.
Source: validated AZ-305 Study Guide, PDF page 36; reference D58. Original learning item; review required.
Backup and disaster recovery
Backup preserves historical states; HA reduces interruption within intended fault boundaries; DR restores service after larger disruption such as regional loss.
Source: validated AZ-305 Study Guide, PDF page 36; reference D33. Original learning item; review required.
Backup and disaster recovery
Replication can copy deletion, corruption, or malware changes; a protected earlier state must survive relevant account/admin compromise.
Source: validated AZ-305 Study Guide, PDF page 36; reference D33. Original learning item; review required.
Backup and disaster recovery
Azure VMs, supported SQL/SAP HANA in VMs, Azure Files, and hybrid protection via MARS/MABS/DPM; it also manages supported Site Recovery.
Source: validated AZ-305 Study Guide, PDF page 36; reference D35. Original learning item; review required.
Backup and disaster recovery
Newer supported data-protection workloads such as Blob, disks, and supported PostgreSQL/Kubernetes; verify the current matrix.
Source: validated AZ-305 Study Guide, PDF page 36; reference D36. Original learning item; review required.
Backup and disaster recovery
Vaults support different workloads and storage/recovery behaviors; Recovery Services vault and Backup vault are not interchangeable.
Source: validated AZ-305 Study Guide, PDF page 36-37; reference D34. Original learning item; review required.
Backup and disaster recovery
No. Operational disk/Blob protection can rely on source snapshots/capabilities; verify where data actually resides.
Source: validated AZ-305 Study Guide, PDF page 37; reference D36. Original learning item; review required.
Backup and disaster recovery
Support varies by workload/vault; GRS does not make every point immediately customer-restorable in any chosen region.
Source: validated AZ-305 Study Guide, PDF page 37; reference D34. Original learning item; review required.
Backup and disaster recovery
A recovery window for deleted backup data. The guide states fourteen-day default and eligible extension up to 180 days, with configuration/rollout qualifications.
Source: validated AZ-305 Study Guide, PDF page 37; reference D37. Original learning item; review required.
Backup and disaster recovery
It blocks destructive changes that would remove protected recovery points before retention expires; locking is irreversible and has support qualifications.
Source: validated AZ-305 Study Guide, PDF page 37; reference D38. Original learning item; review required.
Backup and disaster recovery
Multiuser authorization adds independent permission control for supported sensitive operations; separate Resource Guard control from vault administration.
Source: validated AZ-305 Study Guide, PDF page 37; reference D39. Original learning item; review required.
Backup and disaster recovery
Destructive actions must be detected and recovery performed before the recoverable window expires.
Source: validated AZ-305 Study Guide, PDF page 37; reference D37. Original learning item; review required.
Backup and disaster recovery
Application-consistent points coordinate eligible application state; crash-consistent points resemble sudden power loss and can need log replay.
Source: validated AZ-305 Study Guide, PDF page 37-38; reference D34. Original learning item; review required.
Backup and disaster recovery
Relevant OS/data disks, application state, external shared storage, and dependencies whose loss prevents the application from working.
Source: validated AZ-305 Study Guide, PDF page 37-38; reference D33. Original learning item; review required.
Backup and disaster recovery
It can rebuild disposable configuration and compute, but cannot recreate irreplaceable data never retained.
Source: validated AZ-305 Study Guide, PDF page 38; reference D33. Original learning item; review required.
Backup and disaster recovery
Eligible Windows file/folder protection. It is not a universal Linux or whole-application backup agent.
Source: validated AZ-305 Study Guide, PDF page 37-38; reference D34. Original learning item; review required.
Backup and disaster recovery
Their own supported server, local storage, maintenance, monitoring, and operations, in return for broader supported workload protection.
Source: validated AZ-305 Study Guide, PDF page 38; reference D34. Original learning item; review required.
Backup and disaster recovery
Cluster resources, supported persistent volumes, external secrets/databases, and other state need explicit protection and restore.
Source: validated AZ-305 Study Guide, PDF page 38; reference D34. Original learning item; review required.
Backup and disaster recovery
Replicates and orchestrates failover/recovery for supported machine workloads; source OS/disks/networking and target configuration must meet support rules.
Source: validated AZ-305 Study Guide, PDF page 38; reference D41. Original learning item; review required.
Backup and disaster recovery
Supported Azure VMs and on-premises VMware, Hyper-V, and physical Windows/Linux systems; not every configuration or PaaS service.
Source: validated AZ-305 Study Guide, PDF page 38; reference D42. Original learning item; review required.
Backup and disaster recovery
A supported VMware VM rather than the original physical hardware; failback procedures differ by source platform.
Source: validated AZ-305 Study Guide, PDF page 38; reference D42. Original learning item; review required.
Backup and disaster recovery
Machine groups, startup order, and supported automation/manual actions, with networks/identity ready before dependent database, middleware, and web services.
Source: validated AZ-305 Study Guide, PDF page 38; reference D57. Original learning item; review required.
Backup and disaster recovery
Target networks, DNS, identities/permissions, secrets, quotas/capacity, connectivity, and external dependencies.
Source: validated AZ-305 Study Guide, PDF page 38; reference D57. Original learning item; review required.
Backup and disaster recovery
The source is unavailable and an available recovery point may omit changes that never replicated; select consistency/recovery point against RPO.
Source: validated AZ-305 Study Guide, PDF page 38; reference D41. Original learning item; review required.
Backup and disaster recovery
Establish reverse-direction protection and return service in a controlled supported flow, reconciling writes as needed.
Source: validated AZ-305 Study Guide, PDF page 38; reference D42. Original learning item; review required.
Backup and disaster recovery
Use an isolated target network while production replication continues, validate the complete application and RTO, then clean up.
Source: validated AZ-305 Study Guide, PDF page 38; reference D56. Original learning item; review required.
Backup and disaster recovery
To prevent conflicting names, duplicate writers, and accidental production access during the drill.
Source: validated AZ-305 Study Guide, PDF page 38; reference D56. Original learning item; review required.
Backup and disaster recovery
Native backups restore an earlier/new database; geo-restore can take longer than activating a ready secondary. Forced asynchronous geo-failover can lose recent writes.
Source: validated AZ-305 Study Guide, PDF page 38-39; reference D08. Original learning item; review required.
Backup and disaster recovery
Full supplies baseline; differential includes changes since that full baseline; a valid log chain supports selected-time recovery. Preserve required chain members.
Source: validated AZ-305 Study Guide, PDF page 38-39; reference D52. Original learning item; review required.
Backup and disaster recovery
Frequent workload-aware log backups can support a fifteen-minute RPO when configured and operating as intended; verify successful jobs and usable chain.
Source: validated AZ-305 Study Guide, PDF page 38-39; reference D52. Original learning item; review required.
Backup and disaster recovery
Continuous backup supports PITR within selected retention/API support; regions retain current copies while backup restores an earlier good state.
Source: validated AZ-305 Study Guide, PDF page 39; reference D53. Original learning item; review required.
Backup and disaster recovery
Operational protection uses supported source-account PITR/versioning/soft-delete/change-feed; vaulted backup copies eligible data into a Backup vault and protects against source-account deletion.
Source: validated AZ-305 Study Guide, PDF page 39; reference D40. Original learning item; review required.
Backup and disaster recovery
Replication/sync can propagate bad changes; supported snapshots/backup recover history, while redundancy addresses outage/durability boundaries.
Source: validated AZ-305 Study Guide, PDF page 39; reference D25. Original learning item; review required.
High availability
Sets distribute eligible VMs across local fault/update domains; zones separate supported regional infrastructure; multiregion design addresses regional loss.
Source: validated AZ-305 Study Guide, PDF page 40; reference D63. Original learning item; review required.
High availability
A zonal resource occupies a selected zone; a zone-redundant service distributes supported components across zones, requiring explicit supported configuration.
Source: validated AZ-305 Study Guide, PDF page 40; reference D63. Original learning item; review required.
High availability
Each resource, service tier, configuration, dependency, and surviving capacity must actually support/enable the required fault isolation.
Source: validated AZ-305 Study Guide, PDF page 40; reference D63. Original learning item; review required.
High availability
The remaining two zones must handle required demand or scale within allowed disruption; nominal replica count alone is insufficient.
Source: validated AZ-305 Study Guide, PDF page 40; reference D63. Original learning item; review required.
High availability
Supported spread, healthy traffic routing, replicated/resilient state, sufficient capacity, and equally resilient disks/endpoints/dependencies.
Source: validated AZ-305 Study Guide, PDF page 40; reference D63. Original learning item; review required.
High availability
Worker failure/replacement should not destroy sessions or business records; put state in a resilient service or explicitly replicate it.
Source: validated AZ-305 Study Guide, PDF page 40; reference D63. Original learning item; review required.
High availability
Supported plan/region, enabled zone redundancy, enough instances, and surviving capacity; regional zones and multiregion deployment differ.
Source: validated AZ-305 Study Guide, PDF page 40; reference D64. Original learning item; review required.
High availability
Pod/node placement, replicas, probes, storage, and capacity are workload concerns; a healthy control plane cannot supply an absent application replica.
Source: validated AZ-305 Study Guide, PDF page 40-41; reference D65. Original learning item; review required.
High availability
They constrain eligible voluntary disruption during controlled maintenance; they cannot prevent every involuntary infrastructure failure.
Source: validated AZ-305 Study Guide, PDF page 40-41; reference D65. Original learning item; review required.
High availability
Bounded retries, exponential backoff, timeouts, and idempotent operations, avoiding synchronized overload and endless backlog.
Source: validated AZ-305 Study Guide, PDF page 41; reference D58. Original learning item; review required.
High availability
A failover can interrupt active connections even if committed data survives; reconnect/retry safely rather than assuming connection continuity.
Source: validated AZ-305 Study Guide, PDF page 41; reference D44. Original learning item; review required.
High availability
Useful ability to serve the intended request, including critical dependency effects, so unhealthy workers do not receive traffic merely because the process runs.
Source: validated AZ-305 Study Guide, PDF page 40-41; reference D63. Original learning item; review required.
High availability
Every required zone/recovery configuration, regional failover, historical recovery, or uninterrupted client connections.
Source: validated AZ-305 Study Guide, PDF page 41; reference D44. Original learning item; review required.
High availability
Tier, hardware, region, and replica configuration; verify the exact supported deployment rather than applying a blanket tier assumption.
Source: validated AZ-305 Study Guide, PDF page 41; reference D44. Original learning item; review required.
High availability
Zone redundancy is preview and depends on supported underlying Elastic SAN ZRS availability; configuration-specific checks are necessary.
Source: validated AZ-305 Study Guide, PDF page 41; reference D66. Original learning item; review required.
High availability
Supported availability groups or failover clusters, quorum, synchronization, listener connectivity, client retries, and operational testing.
Source: validated AZ-305 Study Guide, PDF page 41; reference D67. Original learning item; review required.
High availability
Covered synchronous failovers can preserve committed transactions but add coordination/latency; asynchronous regional replicas can lose recent writes.
Source: validated AZ-305 Study Guide, PDF page 41; reference D67. Original learning item; review required.
High availability
Both use supported synchronous availability standbys; only cross-zone placement isolates a full zone failure.
Source: validated AZ-305 Study Guide, PDF page 41; reference D46. Original learning item; review required.
High availability
It is asynchronous and needs promotion/connection planning; local HA standby provides supported synchronous automatic failover.
Source: validated AZ-305 Study Guide, PDF page 41; reference D46. Original learning item; review required.
High availability
ZRS supplies synchronous primary-region zone copies; GZRS adds asynchronous geographic copies, requiring application regional recovery design.
Source: validated AZ-305 Study Guide, PDF page 41; reference D17. Original learning item; review required.
High availability
Potential older/missing object versions and read-only behavior; recovery of compute/network/identity/secrets must accompany data access.
Source: validated AZ-305 Study Guide, PDF page 41; reference D17. Original learning item; review required.
High availability
Use supported ZRS for zone failure; eligible geo-redundant HDD shares can use account failover; SSD lacks GRS/GZRS; clients may need session reconnection.
Source: validated AZ-305 Study Guide, PDF page 41-42; reference D25. Original learning item; review required.
High availability
Per-region zone redundancy, single-/multi-write topology, consistency, SDK preferred regions, failover, conflict handling, and independent backup.
Source: validated AZ-305 Study Guide, PDF page 42; reference D45. Original learning item; review required.
High availability
Active-passive prepares a secondary and may need scale-up/recovery; active-active serves multiple regions but complicates writes/conflicts/consistency.
Source: validated AZ-305 Study Guide, PDF page 42; reference D43. Original learning item; review required.
High availability
Pairing varies and some regions are unpaired; application dependencies still need supported replication, traffic routing, and tested failover.
Source: validated AZ-305 Study Guide, PDF page 42; reference D43. Original learning item; review required.
High availability
For serial dependencies, 0.999 × 0.9995 = 0.9985005 ≈ 99.85%. It models measured independent availability and does not create a contractual application SLA.
Source: validated AZ-305 Study Guide, PDF page 42; reference D58. Original learning item; review required.
Compute design
OS and runtime, packaging, CPU and memory, storage, concurrency, network access, execution duration, startup latency, state, retryability, availability, and the team's operating skills.
Source: AZ-305 Study Guide.pdf, PDF page(s) 43; reference N01. Original study item; requires human review.
Compute design
Azure Virtual Machines; the customer manages guest software, patching, images, disks, networking, availability, and recovery.
Source: AZ-305 Study Guide.pdf, PDF page(s) 43; reference N01. Original study item; requires human review.
Compute design
Azure App Service, after validating runtime, plan capacity, inbound and outbound networking, deployment, and resilience requirements.
Source: AZ-305 Study Guide.pdf, PDF page(s) 43; reference N01. Original study item; requires human review.
Compute design
When they need direct Kubernetes APIs, custom controllers, ecosystem extensions, or deep cluster control that Container Apps abstracts away.
Source: AZ-305 Study Guide.pdf, PDF page(s) 43, 46-47; reference N50. Original study item; requires human review.
Compute design
Managed environments, versioned revisions, KEDA-based scaling, and optional Dapr integration with less cluster management.
Source: AZ-305 Study Guide.pdf, PDF page(s) 43, 46-47; reference N66. Original study item; requires human review.
Compute design
Simple isolated container or container-group execution, such as a one-off task or sidecar group without full application orchestration requirements.
Source: AZ-305 Study Guide.pdf, PDF page(s) 43, 47; reference N50. Original study item; requires human review.
Compute design
Databases, storage, downstream APIs, or connection limits can become bottlenecks; scale must respect the entire dependency path.
Source: AZ-305 Study Guide.pdf, PDF page(s) 44; reference N01. Original study item; requires human review.
Compute design
It stores and shares controlled image versions so deployments are repeatable instead of relying on undocumented manual changes to servers.
Source: AZ-305 Study Guide.pdf, PDF page(s) 44; reference N69. Original study item; requires human review.
Compute design
Eligible Windows Server or SQL Server licenses and compliance with the applicable licensing conditions.
Source: AZ-305 Study Guide.pdf, PDF page(s) 44; reference N70. Original study item; requires human review.
Compute design
Use a managed identity and grant that identity the required service permissions.
Source: AZ-305 Study Guide.pdf, PDF page(s) 44; reference N01. Original study item; requires human review.
Compute design
Match measured balanced demand, large working sets, sustained CPU work, supported graphics or ML acceleration, or specialized parallel computation respectively; then check the exact SKU limits.
Source: AZ-305 Study Guide.pdf, PDF page(s) 44; reference N01. Original study item; requires human review.
Compute design
The lower disk-level or aggregate VM limit constrains achievable IOPS and throughput even when an attached disk has higher advertised performance.
Source: AZ-305 Study Guide.pdf, PDF page(s) 44; reference N34. Original study item; requires human review.
Compute design
Many small random reads or writes stress operations per second; large sequential transfers tend to stress MB/s.
Source: AZ-305 Study Guide.pdf, PDF page(s) 44; reference N34. Original study item; requires human review.
Compute design
On managed data disks or an appropriate managed data service, rather than temporary local storage.
Source: AZ-305 Study Guide.pdf, PDF page(s) 44; reference N34. Original study item; requires human review.
Compute design
Stateless replaceable instances whose OS can be recreated from a controlled image; it is local storage and is unsuitable for preserving stateful OS changes.
Source: AZ-305 Study Guide.pdf, PDF page(s) 44; reference N34. Original study item; requires human review.
Compute design
Premium SSD v2 and Ultra Disk; verify supported VMs, regions, zones, and feature constraints.
Source: AZ-305 Study Guide.pdf, PDF page(s) 45; reference N34. Original study item; requires human review.
Compute design
Capacity, provisioned IOPS, and throughput can be configured separately, within supported constraints.
Source: AZ-305 Study Guide.pdf, PDF page(s) 45; reference N34. Original study item; requires human review.
Compute design
Standard SSD suits moderate and cost-sensitive workloads; Premium SSD suits production needing lower latency; Ultra Disk suits supported demanding high-performance data workloads.
Source: AZ-305 Study Guide.pdf, PDF page(s) 45; reference N34. Original study item; requires human review.
Compute design
Their use as OS disks retires on September 8, 2028; prefer an SSD-based OS disk design and review migration guidance.
Source: AZ-305 Study Guide.pdf, PDF page(s) 45; reference N34. Original study item; requires human review.
Compute design
Scale out adds instances; scale in removes instances; scale up increases resources per instance.
Source: AZ-305 Study Guide.pdf, PDF page(s) 45; reference N02. Original study item; requires human review.
Compute design
Realistic thresholds, aggregation windows, cooldowns, and minimum and maximum counts, using a metric that represents the workload bottleneck.
Source: AZ-305 Study Guide.pdf, PDF page(s) 45; reference N02. Original study item; requires human review.
Compute design
It measures pending work directly; CPU may stay low while workers wait on a constrained dependency.
Source: AZ-305 Study Guide.pdf, PDF page(s) 45; reference N02. Original study item; requires human review.
Compute design
Graceful task draining and appropriate instance protection, combined with retry-safe processing and durable state.
Source: AZ-305 Study Guide.pdf, PDF page(s) 45; reference N02. Original study item; requires human review.
Compute design
Uniform uses common-profile scale-set child instance APIs; Flexible manages standard Azure VMs with ordinary VM APIs and more individual control.
Source: AZ-305 Study Guide.pdf, PDF page(s) 45; reference N02. Original study item; requires human review.
Compute design
Yes. Current support includes autoscaling and upgrade policies; verify the exact feature matrix instead of repeating obsolete no-autoscale claims.
Source: AZ-305 Study Guide.pdf, PDF page(s) 45; reference N02. Original study item; requires human review.
Compute design
Its instances are standard Azure VMs, enabling standard supported integrations such as Azure Backup and Site Recovery that are not equivalent for Uniform child instances.
Source: AZ-305 Study Guide.pdf, PDF page(s) 45; reference N02. Original study item; requires human review.
Compute design
Sets distribute supported VMs across local fault and update domains; zones separate supported resources across independent regional power, cooling, and networking locations.
Source: AZ-305 Study Guide.pdf, PDF page(s) 45; reference N02. Original study item; requires human review.
Compute design
The remaining zones must absorb the failed zone's work without breaching latency or availability objectives.
Source: AZ-305 Study Guide.pdf, PDF page(s) 45; reference N02. Original study item; requires human review.
Compute design
Quota is the subscription's allocation permission; capacity is available hardware for the SKU and location. A quota increase does not create capacity.
Source: AZ-305 Study Guide.pdf, PDF page(s) 45; reference N03. Original study item; requires human review.
Compute design
A successful supported capacity reservation secures quantity and location; Reserved VM Instances provide a term billing discount without guaranteeing hardware availability.
Source: AZ-305 Study Guide.pdf, PDF page(s) 45; reference N03. Original study item; requires human review.
Compute design
Spare capacity can be reclaimed and Spot VMs evicted; the workload needs interruption tolerance or a dedicated-capacity baseline.
Source: AZ-305 Study Guide.pdf, PDF page(s) 45; reference N33. Original study item; requires human review.
Compute design
Worker location, operating system, pricing tier, size, and count; one or more apps and their slots use those workers.
Source: AZ-305 Study Guide.pdf, PDF page(s) 46; reference N04. Original study item; requires human review.
Compute design
Apps and slots on the same App Service plan share compute resources.
Source: AZ-305 Study Guide.pdf, PDF page(s) 46; reference N04. Original study item; requires human review.
Compute design
When they need independent scaling, resource isolation, different operating systems, or separate failure boundaries.
Source: AZ-305 Study Guide.pdf, PDF page(s) 46; reference N04. Original study item; requires human review.
Compute design
No. Allocated plan compute generally continues to incur charges while the plan exists.
Source: AZ-305 Study Guide.pdf, PDF page(s) 46; reference N04. Original study item; requires human review.
Compute design
Standard and higher tiers; other capabilities, such as zones or private access, have separate tier and infrastructure prerequisites.
Source: AZ-305 Study Guide.pdf, PDF page(s) 46; reference N04. Original study item; requires human review.
Compute design
At least two plan instances for supported Premium v2 through v4 configurations; check region, infrastructure, available zones, and autoscale minimums.
Source: AZ-305 Study Guide.pdf, PDF page(s) 46; reference N05. Original study item; requires human review.
Compute design
Plan worker distribution and per-app worker limits differ; a limit of one can leave no simultaneous hot app instance elsewhere.
Source: AZ-305 Study Guide.pdf, PDF page(s) 46; reference N05. Original study item; requires human review.
Compute design
It keeps environment-specific configuration, such as a production connection string, attached to the intended slot during swaps.
Source: AZ-305 Study Guide.pdf, PDF page(s) 46; reference N45. Original study item; requires human review.
Compute design
An incompatible database schema or data change; routing or application rollback needs data compatibility.
Source: AZ-305 Study Guide.pdf, PDF page(s) 46; reference N45. Original study item; requires human review.
Compute design
Private endpoints or access restrictions control inbound callers; VNet integration lets the app reach private outbound dependencies and does not itself privatize ingress.
Source: AZ-305 Study Guide.pdf, PDF page(s) 46; reference N01. Original study item; requires human review.
Compute design
Authorize registry pulls, scan and patch dependencies, rebuild controlled images, and deploy versioned artifacts or immutable digests.
Source: AZ-305 Study Guide.pdf, PDF page(s) 46; reference N50. Original study item; requires human review.
Compute design
No. It stores and distributes artifacts; a compute host executes them.
Source: AZ-305 Study Guide.pdf, PDF page(s) 46; reference N50. Original study item; requires human review.
Compute design
A deployment maintains pod replicas; a service provides stable access; an ingress implementation handles application routing.
Source: AZ-305 Study Guide.pdf, PDF page(s) 46; reference N65. Original study item; requires human review.
Compute design
Pod autoscaling changes replica counts; cluster autoscaling adds node capacity when schedulable pods cannot fit.
Source: AZ-305 Study Guide.pdf, PDF page(s) 46; reference N65. Original study item; requires human review.
Compute design
Resource requests and limits, multiple replicas, topology spread, readiness and liveness probes, disruption budgets, and appropriate persistent data replication.
Source: AZ-305 Study Guide.pdf, PDF page(s) 46; reference N65. Original study item; requires human review.
Compute design
Multiple active revisions enable gradual traffic shifts; a positive minimum replica count reduces scale-to-zero startup delay.
Source: AZ-305 Study Guide.pdf, PDF page(s) 46-47; reference N66. Original study item; requires human review.
Compute design
Hosts can be replaced and concurrent executions can run on different instances, so memory is not a durable shared state store.
Source: AZ-305 Study Guide.pdf, PDF page(s) 47; reference N06. Original study item; requires human review.
Compute design
Flex Consumption, subject to supported OS, language, resource, and networking requirements; optional always-ready capacity can reduce startup delay.
Source: AZ-305 Study Guide.pdf, PDF page(s) 47; reference N06. Original study item; requires human review.
Compute design
When prewarmed capacity, low startup latency, sustained demand, private networking, or supported custom Linux containers are required, accepting minimum provisioned cost.
Source: AZ-305 Study Guide.pdf, PDF page(s) 47; reference N06. Original study item; requires human review.
Compute design
It uses allocated App Service capacity with manual or plan autoscale; enable Always On when required.
Source: AZ-305 Study Guide.pdf, PDF page(s) 47; reference N06. Original study item; requires human review.
Compute design
It persists workflow progress and orchestrates activities for patterns such as chaining, fan-out/fan-in, asynchronous processing, monitoring, and human approval.
Source: AZ-305 Study Guide.pdf, PDF page(s) 47; reference N53. Original study item; requires human review.
Compute design
History is replayed to rebuild workflow state; put external calls and nondeterministic work into activities or use documented deterministic orchestration APIs.
Source: AZ-305 Study Guide.pdf, PDF page(s) 47; reference N63. Original study item; requires human review.
Compute design
No. Activities can be retried, so idempotency and correct transaction boundaries remain necessary.
Source: AZ-305 Study Guide.pdf, PDF page(s) 47; reference N53. Original study item; requires human review.
Compute design
Legacy Consumption defaults to five minutes and permits ten; Flex, Premium, and Dedicated default to 30 minutes and permit unbounded configuration under documented conditions.
Source: AZ-305 Study Guide.pdf, PDF page(s) 47-48; reference N06. Original study item; requires human review.
Compute design
The documented HTTP response limit is 230 seconds; use an accepted response with status tracking and asynchronous queued or durable work.
Source: AZ-305 Study Guide.pdf, PDF page(s) 47-48; reference N06. Original study item; requires human review.
Compute design
A pool defines compute nodes, a job groups work and policies, a task executes a command, and a start task prepares a node's software environment.
Source: AZ-305 Study Guide.pdf, PDF page(s) 48; reference N51. Original study item; requires human review.
Compute design
Persist results in durable storage; use retryable or checkpointed Spot tasks for flexible work and dedicated or mixed capacity for reliable completion.
Source: AZ-305 Study Guide.pdf, PDF page(s) 48; reference N51. Original study item; requires human review.
Compute design
Multi-instance tasks fit supported tightly coupled jobs such as MPI; CycleCloud fits HPC needing a specific scheduler and custom cluster topology that the team operates.
Source: AZ-305 Study Guide.pdf, PDF page(s) 48; reference N51. Original study item; requires human review.
Application architecture
A command requests an operation; an event announces something that happened; a stream records a retained sequence of observations.
Source: AZ-305 Study Guide.pdf, PDF page(s) 49; reference N07. Original study item; requires human review.
Application architecture
When an immediate result is required and the call fits the supported latency and timeout budget, accounting for dependency failure.
Source: AZ-305 Study Guide.pdf, PDF page(s) 49; reference N07. Original study item; requires human review.
Application architecture
It buffers bursts for sustainable consumer processing; users need accepted or pending state, status tracking, and meaningful eventual failure handling.
Source: AZ-305 Study Guide.pdf, PDF page(s) 49; reference N29. Original study item; requires human review.
Application architecture
Azure Service Bus queues, using brokered messages, acknowledgments, locks, and supported reliability features.
Source: AZ-305 Study Guide.pdf, PDF page(s) 49; reference N07. Original study item; requires human review.
Application architecture
Queue consumers divide one work stream; each topic subscription receives an independent logical copy, with competing workers within that subscription.
Source: AZ-305 Study Guide.pdf, PDF page(s) 49-50; reference N08. Original study item; requires human review.
Application architecture
Azure Event Grid; subscriptions filter and route events to interested handlers.
Source: AZ-305 Study Guide.pdf, PDF page(s) 49, 51; reference N07. Original study item; requires human review.
Application architecture
Azure Event Hubs, using retained partitions, consumer groups, and checkpoints.
Source: AZ-305 Study Guide.pdf, PDF page(s) 49, 51; reference N43. Original study item; requires human review.
Application architecture
For straightforward inexpensive durable work queues when application-supplied poison handling and simpler processing semantics are acceptable.
Source: AZ-305 Study Guide.pdf, PDF page(s) 49, 51; reference N29. Original study item; requires human review.
Application architecture
A receiver locks a message, processes it, and completes it after success; abandonment or lock expiry permits redelivery.
Source: AZ-305 Study Guide.pdf, PDF page(s) 50; reference N08. Original study item; requires human review.
Application architecture
The message is removed at receipt, so a consumer crash before processing can lose the work.
Source: AZ-305 Study Guide.pdf, PDF page(s) 50; reference N08. Original study item; requires human review.
Application architecture
For supported processing that legitimately outlasts a delivery lock; avoid holding a lock through unnecessarily long interactions.
Source: AZ-305 Study Guide.pdf, PDF page(s) 50; reference N08. Original study item; requires human review.
Application architecture
Repeated sends with the same application-supplied MessageId inside the configured deduplication window.
Source: AZ-305 Study Guide.pdf, PDF page(s) 50; reference N30. Original study item; requires human review.
Application architecture
A worker can commit the database write and lose the message lock before completion; redelivery still needs idempotent business processing.
Source: AZ-305 Study Guide.pdf, PDF page(s) 50; reference N30. Original study item; requires human review.
Application architecture
Use a stable business identifier with a uniqueness constraint or a transactional processed-message record.
Source: AZ-305 Study Guide.pdf, PDF page(s) 50; reference N08. Original study item; requires human review.
Application architecture
Each subscription selects messages using supported broker properties or SQL-style rules while maintaining its independent receipt and processing.
Source: AZ-305 Study Guide.pdf, PDF page(s) 50; reference N08. Original study item; requires human review.
Application architecture
Exclusive session ownership and ordered processing for related messages sharing a SessionId, with supported session state.
Source: AZ-305 Study Guide.pdf, PDF page(s) 50; reference N29. Original study item; requires human review.
Application architecture
Independent sessions preserve required local order while allowing concurrency; one global order unnecessarily serializes unrelated work.
Source: AZ-305 Study Guide.pdf, PDF page(s) 50; reference N29. Original study item; requires human review.
Application architecture
It retains unsuccessfully delivered or explicitly rejected messages for inspection; monitoring, ownership, correction, and controlled replay are still required.
Source: AZ-305 Study Guide.pdf, PDF page(s) 50-51; reference N08. Original study item; requires human review.
Application architecture
Deferral retains a received message for later retrieval when prerequisites are missing; scheduling delays the message's initial availability.
Source: AZ-305 Study Guide.pdf, PDF page(s) 51; reference N08. Original study item; requires human review.
Application architecture
How long the work remains useful; expired work should follow explicit business handling rather than unlimited retries.
Source: AZ-305 Study Guide.pdf, PDF page(s) 51; reference N08. Original study item; requires human review.
Application architecture
Basic supplies simpler queues; Standard adds topics, sessions, transactions, and duplicate detection; Premium supplies dedicated messaging capacity and supported private connectivity.
Source: AZ-305 Study Guide.pdf, PDF page(s) 51; reference N29. Original study item; requires human review.
Application architecture
It coordinates supported broker operations, not an arbitrary database write and message publication as one distributed transaction.
Source: AZ-305 Study Guide.pdf, PDF page(s) 51; reference N29. Original study item; requires human review.
Application architecture
Commit the business change and outgoing-message record in one database transaction, then use a reliable dispatcher to publish the record.
Source: AZ-305 Study Guide.pdf, PDF page(s) 51; reference N29. Original study item; requires human review.
Application architecture
The ID supports idempotent handling, and a reference avoids putting large content inside a notification.
Source: AZ-305 Study Guide.pdf, PDF page(s) 51; reference N44. Original study item; requires human review.
Application architecture
No; consumers must handle repeated and potentially out-of-order events appropriately.
Source: AZ-305 Study Guide.pdf, PDF page(s) 51; reference N44. Original study item; requires human review.
Application architecture
Configure supported retries and dead-letter storage, distinguish permanent response failures, monitor delivery failures and latency, and acknowledge only after safe acceptance.
Source: AZ-305 Study Guide.pdf, PDF page(s) 51; reference N44. Original study item; requires human review.
Application architecture
Pull delivery with receive, acknowledge, release, reject, and lock-renewal semantics; Event Grid is not universally webhook-only.
Source: AZ-305 Study Guide.pdf, PDF page(s) 51; reference N31. Original study item; requires human review.
Application architecture
It groups related events on one ordered partition, while other partitions progress independently.
Source: AZ-305 Study Guide.pdf, PDF page(s) 51; reference N43. Original study item; requires human review.
Application architecture
An independent reading view for an application, with its own progression and checkpoints.
Source: AZ-305 Study Guide.pdf, PDF page(s) 51; reference N43. Original study item; requires human review.
Application architecture
A checkpoint records progress; committing it first can skip work after a crash.
Source: AZ-305 Study Guide.pdf, PDF page(s) 51; reference N43. Original study item; requires human review.
Application architecture
Useful parallelism is constrained by partitions, ownership, capacity, and key distribution; a hot partition can dominate.
Source: AZ-305 Study Guide.pdf, PDF page(s) 51; reference N43. Original study item; requires human review.
Application architecture
Automatic storage of events in supported Blob Storage or Data Lake storage for archival and batch analysis; it does not replace live-consumer lag monitoring.
Source: AZ-305 Study Guide.pdf, PDF page(s) 51; reference N43. Original study item; requires human review.
Application architecture
Retrieved messages are temporarily hidden; consumers delete after success, while failure can make the message visible again.
Source: AZ-305 Study Guide.pdf, PDF page(s) 51; reference N29. Original study item; requires human review.
Application architecture
Inspect dequeue count and move repeatedly failing messages to a separate application-managed poison queue.
Source: AZ-305 Study Guide.pdf, PDF page(s) 51; reference N29. Original study item; requires human review.
Application architecture
Put the payload in Blob Storage and send a secure reference, respecting message limits and encoding overhead.
Source: AZ-305 Study Guide.pdf, PDF page(s) 51; reference N29. Original study item; requires human review.
Application architecture
Backoff spaces retries, jitter spreads them across clients, and a circuit breaker limits repeated calls while the dependency remains unhealthy.
Source: AZ-305 Study Guide.pdf, PDF page(s) 52; reference N29. Original study item; requires human review.
Application architecture
Queue age, backlog, and consumer lag; cap worker concurrency to the downstream service's sustainable rate.
Source: AZ-305 Study Guide.pdf, PDF page(s) 52; reference N07. Original study item; requires human review.
Application architecture
API publication, contracts, versions, subscriptions, gateway policies, usage controls, observability, and a developer portal.
Source: AZ-305 Study Guide.pdf, PDF page(s) 52; reference N64. Original study item; requires human review.
Application architecture
Issuer, audience, expiry, and required permissions or claims; a token valid for another API is insufficient.
Source: AZ-305 Study Guide.pdf, PDF page(s) 52; reference N64. Original study item; requires human review.
Application architecture
It identifies an APIM subscription for usage controls; sensitive APIs also require authenticated identity and authorization.
Source: AZ-305 Study Guide.pdf, PDF page(s) 52; reference N64. Original study item; requires human review.
Application architecture
Use a gateway managed identity with the backend's required permissions; protect other credentials with Key Vault where needed.
Source: AZ-305 Study Guide.pdf, PDF page(s) 52; reference N48. Original study item; requires human review.
Application architecture
Developer classic; production use requires an appropriate production tier and design.
Source: AZ-305 Study Guide.pdf, PDF page(s) 52; reference N48. Original study item; requires human review.
Application architecture
It lacks a built-in internal cache; use a supported external cache if the design needs gateway caching.
Source: AZ-305 Study Guide.pdf, PDF page(s) 52-53; reference N10. Original study item; requires human review.
Application architecture
It lets the gateway reach private VNet backends while its public gateway remains reachable; it does not itself imply fully private ingress.
Source: AZ-305 Study Guide.pdf, PDF page(s) 52; reference N09. Original study item; requires human review.
Application architecture
Premium classic where supported; Premium v2 does not imply these classic capabilities.
Source: AZ-305 Study Guide.pdf, PDF page(s) 52; reference N48. Original study item; requires human review.
Application architecture
Rate limits constrain short-window bursts; quotas constrain consumption allowance over a longer interval.
Source: AZ-305 Study Guide.pdf, PDF page(s) 52; reference N48. Original study item; requires human review.
Application architecture
Check cache, read the authoritative database on a miss, then cache the result for a suitable TTL.
Source: AZ-305 Study Guide.pdf, PDF page(s) 53; reference N68. Original study item; requires human review.
Application architecture
Invalidate or update them so stale copies do not outlive the acceptable freshness period.
Source: AZ-305 Study Guide.pdf, PDF page(s) 53; reference N68. Original study item; requires human review.
Application architecture
In-process caches are separate per instance; a distributed cache provides shared cached data across instances.
Source: AZ-305 Study Guide.pdf, PDF page(s) 53; reference N10. Original study item; requires human review.
Application architecture
Azure Managed Redis, sized for working set, concurrency, throughput, eviction, private access, and resilience.
Source: AZ-305 Study Guide.pdf, PDF page(s) 53; reference N11. Original study item; requires human review.
Application architecture
Enterprise and Enterprise Flash retire March 31, 2027; Basic, Standard, and Premium retire September 30, 2028. The planned October 2026 existing-customer creation block was removed.
Source: AZ-305 Study Guide.pdf, PDF page(s) 53; reference N47. Original study item; requires human review.
Application architecture
Scope cache keys and response variation by tenant, identity, query, and relevant headers, and cache only appropriately reusable content.
Source: AZ-305 Study Guide.pdf, PDF page(s) 53; reference N10. Original study item; requires human review.
Application architecture
A cache stampede creates simultaneous misses; request coalescing, staggered expiry, prewarming, and bounded fallback concurrency limit pressure.
Source: AZ-305 Study Guide.pdf, PDF page(s) 53; reference N68. Original study item; requires human review.
Application architecture
Labels distinguish environments or versions; snapshots are named immutable selected configuration sets; feature flags control enablement independently of code release.
Source: AZ-305 Study Guide.pdf, PDF page(s) 53; reference N52. Original study item; requires human review.
Application architecture
Keep secrets in Key Vault, use App Configuration references where useful, and grant the application identity separate rights to read configuration and retrieve referenced secrets.
Source: AZ-305 Study Guide.pdf, PDF page(s) 53-54; reference N27. Original study item; requires human review.
Application architecture
Build once, validate and publish an immutable artifact, deploy it to controlled environments, verify useful health, and promote the same version into production with controlled configuration and secret references.
Source: AZ-305 Study Guide.pdf, PDF page(s) 54; reference N67. Original study item; requires human review.
Application architecture
ARM templates describe deployments as JSON; Bicep is an Azure-native declarative language with reusable modules that compiles to ARM templates.
Source: AZ-305 Study Guide.pdf, PDF page(s) 54; reference N67. Original study item; requires human review.
Application architecture
State tracks provider-managed resources and can contain sensitive values; a secured shared backend protects it, and locking coordinates competing deployments.
Source: AZ-305 Study Guide.pdf, PDF page(s) 54; reference N67. Original study item; requires human review.
Application architecture
Rolling replaces instances gradually; blue-green runs old and new environments side by side and switches traffic; canary initially routes a small traffic share to the new version and expands on health evidence.
Source: AZ-305 Study Guide.pdf, PDF page(s) 54; reference N45. Original study item; requires human review.
Application architecture
Old and new versions share a compatible schema during rollout; remove obsolete fields only after the old version is retired.
Source: AZ-305 Study Guide.pdf, PDF page(s) 54; reference N45. Original study item; requires human review.
Application architecture
Feature flags control enablement rather than permissions; a caller can invoke an endpoint even when its UI button is hidden.
Source: AZ-305 Study Guide.pdf, PDF page(s) 53; reference N27. Original study item; requires human review.
Application architecture
Edge caching reuses HTTP content near users; a distributed cache supplies reusable data to backend application code, so they act at different parts of the request path.
Source: AZ-305 Study Guide.pdf, PDF page(s) 53; reference N10. Original study item; requires human review.
Network design
Overlapping ranges prevent ordinary VNet peering and complicate hybrid route selection and address translation.
Source: AZ-305 Study Guide.pdf, PDF page(s) 55; reference N35. Original study item; requires human review.
Network design
Growth, private endpoints, container networking, and dedicated service subnets such as GatewaySubnet, AzureFirewallSubnet, and AzureBastionSubnet.
Source: AZ-305 Study Guide.pdf, PDF page(s) 55; reference N35. Original study item; requires human review.
Network design
Default routes and allowed communication can connect resources; explicit NSG, firewall, and routing controls enforce the intended restrictions.
Source: AZ-305 Study Guide.pdf, PDF page(s) 55; reference N39. Original study item; requires human review.
Network design
Private IP communication over Microsoft's backbone between two supported nonoverlapping VNets, including supported global peering.
Source: AZ-305 Study Guide.pdf, PDF page(s) 55; reference N35. Original study item; requires human review.
Network design
Ordinary VNet peering is nontransitive; use direct peering or deliberately routed and forwarded hub transit.
Source: AZ-305 Study Guide.pdf, PDF page(s) 55; reference N35. Original study item; requires human review.
Network design
Supported peering settings let it use a hub's gateway; this does not independently establish automatic spoke-to-spoke forwarding.
Source: AZ-305 Study Guide.pdf, PDF page(s) 55; reference N35. Original study item; requires human review.
Network design
When many branches, VNets, and regions make connectivity and routing complex; managed virtual hubs can centralize supported connectivity.
Source: AZ-305 Study Guide.pdf, PDF page(s) 55; reference N21. Original study item; requires human review.
Network design
Managed hubs do not imply unrestricted universal reachability; route tables, propagation, routing intent, and segmentation govern paths.
Source: AZ-305 Study Guide.pdf, PDF page(s) 55; reference N21. Original study item; requires human review.
Network design
Scalable outbound SNAT using a controlled public source-address set, with connection capacity planning.
Source: AZ-305 Study Guide.pdf, PDF page(s) 55; reference N40. Original study item; requires human review.
Network design
No. It supplies outbound translation, not public application ingress or application-aware inspection.
Source: AZ-305 Study Guide.pdf, PDF page(s) 55; reference N40. Original study item; requires human review.
Network design
No. The chosen route still steers traffic to the appliance; design both the path and final egress address intentionally.
Source: AZ-305 Study Guide.pdf, PDF page(s) 55-56; reference N57. Original study item; requires human review.
Network design
SNAT port exhaustion or connection pressure can occur; reuse connections and monitor capacity before expanding the egress design.
Source: AZ-305 Study Guide.pdf, PDF page(s) 55-56; reference N40. Original study item; requires human review.
Network design
New VNets using API versions released after that date default their subnets to private with defaultOutboundAccess false; existing VNets are not automatically converted.
Source: AZ-305 Study Guide.pdf, PDF page(s) 56; reference N12. Original study item; requires human review.
Network design
NAT Gateway, a correctly routed firewall or NVA, Standard public Load Balancer outbound rules, or an explicitly assigned VM public IP.
Source: AZ-305 Study Guide.pdf, PDF page(s) 56; reference N12. Original study item; requires human review.
Network design
Stop and deallocate affected VMs as required so NIC-level default outbound assignment is cleared.
Source: AZ-305 Study Guide.pdf, PDF page(s) 56; reference N12. Original study item; requires human review.
Network design
Standard; Basic Load Balancer retired September 30, 2025.
Source: AZ-305 Study Guide.pdf, PDF page(s) 56; reference N61. Original study item; requires human review.
Network design
Site-to-site connects an on-premises network through an IPsec/IKE tunnel; point-to-site connects an individual remote client.
Source: AZ-305 Study Guide.pdf, PDF page(s) 56; reference N58. Original study item; requires human review.
Network design
The on-premises VPN device and remote address spaces; the Azure virtual network gateway terminates the Azure tunnel.
Source: AZ-305 Study Guide.pdf, PDF page(s) 56; reference N58. Original study item; requires human review.
Network design
Supported active-active Azure gateways, redundant on-premises devices and tunnels, correct return routes, and verified surviving capacity.
Source: AZ-305 Study Guide.pdf, PDF page(s) 56; reference N58. Original study item; requires human review.
Network design
The supported gateway, tunnel protocol, client, and identity combinations, including certificates, RADIUS, or Microsoft Entra ID.
Source: AZ-305 Study Guide.pdf, PDF page(s) 56; reference N58. Original study item; requires human review.
Network design
The circuit is a logical provider or Direct connection with peering location and bandwidth; the gateway connects a VNet to that circuit.
Source: AZ-305 Study Guide.pdf, PDF page(s) 56; reference N22. Original study item; requires human review.
Network design
Private peering carries routes between on-premises and Azure VNets; Microsoft peering reaches supported Microsoft public services under documented requirements.
Source: AZ-305 Study Guide.pdf, PDF page(s) 56; reference N22. Original study item; requires human review.
Network design
No. Private connectivity alone is not encryption; select TLS or supported network encryption according to the required protection scope.
Source: AZ-305 Study Guide.pdf, PDF page(s) 56; reference N22. Original study item; requires human review.
Network design
TLS protects application traffic; supported IPsec protects the network tunnel end to end; MACsec protects the supported Direct physical-link segment.
Source: AZ-305 Study Guide.pdf, PDF page(s) 56-57; reference N22. Original study item; requires human review.
Network design
It lets eligible traffic bypass the gateway data path to improve performance while the gateway remains required for route exchange.
Source: AZ-305 Study Guide.pdf, PDF page(s) 57; reference N36. Original study item; requires human review.
Network design
Supported ExpressRoute circuits to connect on-premises sites through Microsoft's backbone; it is not VNet peering.
Source: AZ-305 Study Guide.pdf, PDF page(s) 57; reference N37. Original study item; requires human review.
Network design
Its bandwidth, route coverage, DNS, and firewall behavior may be insufficient for the surviving production load.
Source: AZ-305 Study Guide.pdf, PDF page(s) 57; reference N22. Original study item; requires human review.
Network design
Choose the most specific matching destination prefix, then apply route-type precedence and documented service exceptions.
Source: AZ-305 Study Guide.pdf, PDF page(s) 57; reference N57. Original study item; requires human review.
Network design
User-defined routes before BGP-learned routes before system routes, subject to documented exceptions.
Source: AZ-305 Study Guide.pdf, PDF page(s) 57; reference N57. Original study item; requires human review.
Network design
Routes with the Virtual network service endpoint next hop cannot be overridden by a UDR.
Source: AZ-305 Study Guide.pdf, PDF page(s) 57; reference N57. Original study item; requires human review.
Network design
No. That UDR next-hop type is supported for VPN gateways, not ExpressRoute gateways.
Source: AZ-305 Study Guide.pdf, PDF page(s) 57; reference N57. Original study item; requires human review.
Network design
Appropriate NIC and guest IP forwarding, actual routing, inspection policy, and coherent return paths.
Source: AZ-305 Study Guide.pdf, PDF page(s) 57; reference N57. Original study item; requires human review.
Network design
The firewall may see only one direction or replies may reach an incompatible state path, preventing valid session tracking.
Source: AZ-305 Study Guide.pdf, PDF page(s) 57; reference N57. Original study item; requires human review.
Network design
Check effective routes, next hop, applicable NSGs, and packet flow; use Network Watcher connection troubleshooting, IP flow verification, and packet capture.
Source: AZ-305 Study Guide.pdf, PDF page(s) 57; reference N57. Original study item; requires human review.
Network design
A VNet network interface with a private IP that maps through Private Link to a specific supported resource or subresource.
Source: AZ-305 Study Guide.pdf, PDF page(s) 57; reference N38. Original study item; requires human review.
Network design
Blob, file, and other subresources have separate supported endpoint targets and DNS needs.
Source: AZ-305 Study Guide.pdf, PDF page(s) 57; reference N38. Original study item; requires human review.
Network design
Not necessarily; configure public network access and service firewall settings separately.
Source: AZ-305 Study Guide.pdf, PDF page(s) 57; reference N38. Original study item; requires human review.
Network design
A service endpoint identifies an allowed VNet subnet while using the service public endpoint; a private endpoint gives a private VNet address to a selected resource connection.
Source: AZ-305 Study Guide.pdf, PDF page(s) 57-58; reference N59. Original study item; requires human review.
Network design
VPN or ExpressRoute private reachability, correct service-name DNS resolution to the private IP, approved connection, and valid application authorization.
Source: AZ-305 Study Guide.pdf, PDF page(s) 57-58; reference N38. Original study item; requires human review.
Network design
It preserves TLS certificate matching and SDK behavior while private DNS resolves that name to the appropriate private endpoint.
Source: AZ-305 Study Guide.pdf, PDF page(s) 58; reference N38. Original study item; requires human review.
Network design
It makes the zone's private records available for appropriate name resolution in that VNet; links must cover the intended client networks.
Source: AZ-305 Study Guide.pdf, PDF page(s) 58; reference N23. Original study item; requires human review.
Network design
Inbound endpoints accept forwarded queries from connected networks; outbound endpoints and forwarding rulesets send selected Azure queries toward external DNS such as on-premises servers.
Source: AZ-305 Study Guide.pdf, PDF page(s) 58; reference N23. Original study item; requires human review.
Network design
Missing links, wrong forwarding, or loops can produce public answers or inconsistent resolution despite valid private packet routes.
Source: AZ-305 Study Guide.pdf, PDF page(s) 58; reference N23. Original study item; requires human review.
Network design
Lower numbers are evaluated first and the first matching rule applies; traffic must pass applicable controls at both subnet and NIC scopes.
Source: AZ-305 Study Guide.pdf, PDF page(s) 58-59; reference N39. Original study item; requires human review.
Network design
ASGs group selected NICs by application role; service tags are maintained Azure service-prefix sets and are not user identities.
Source: AZ-305 Study Guide.pdf, PDF page(s) 59; reference N39. Original study item; requires human review.
Network design
NSGs provide stateful network and port filtering; Firewall centralizes network/application inspection; WAF inspects HTTP attacks.
Source: AZ-305 Study Guide.pdf, PDF page(s) 59; reference N41. Original study item; requires human review.
Network design
Supported TLS inspection and intrusion detection and prevention, with configuration and application compatibility requirements.
Source: AZ-305 Study Guide.pdf, PDF page(s) 59; reference N41. Original study item; requires human review.
Network design
Managed RDP or SSH over a secure connection without a public IP on each target VM, subject to tier, access, and deployment requirements.
Source: AZ-305 Study Guide.pdf, PDF page(s) 59; reference N42. Original study item; requires human review.
Network design
DDoS protects against network flooding; WAF filters application-layer HTTP attacks. Paid IP and Network Protection offer different supported resource scopes.
Source: AZ-305 Study Guide.pdf, PDF page(s) 59; reference N26. Original study item; requires human review.
Network design
For regional public or private TCP/UDP distribution to healthy VM or scale-set backends without HTTP path routing or TLS termination.
Source: AZ-305 Study Guide.pdf, PDF page(s) 59-60; reference N24. Original study item; requires human review.
Network design
Regional HTTP/HTTPS host and path routing, TLS termination, health probes, and optional WAF in a dedicated VNet subnet.
Source: AZ-305 Study Guide.pdf, PDF page(s) 59-60; reference N24. Original study item; requires human review.
Network design
Both offer global HTTP edge routing and caching; Premium supports Private Link origins and managed WAF rules, while Standard supports custom WAF rules.
Source: AZ-305 Study Guide.pdf, PDF page(s) 59-60; reference N24. Original study item; requires human review.
Network design
Traffic Manager selects global endpoints through DNS without proxying packets; global Load Balancer provides supported cross-region Layer 4 distribution to regional public Standard Load Balancers.
Source: AZ-305 Study Guide.pdf, PDF page(s) 59-60; reference N60. Original study item; requires human review.
Network design
DNS caches and existing connections can delay changes, exposed origins can bypass policy, and a responding process may still lack required healthy dependencies.
Source: AZ-305 Study Guide.pdf, PDF page(s) 60; reference N24. Original study item; requires human review.
Network design
Application Gateway v1 retired April 28, 2026; Front Door classic retires March 31, 2027. Use Application Gateway v2 and Front Door Standard or Premium, and plan supported migration.
Source: AZ-305 Study Guide.pdf, PDF page 60; references N13 and N25. Original study item; requires human review.
Migration design
Moving a workload with minimal change, such as moving a supported VM to Azure Virtual Machines.
Source guide: PDF page(s) 61.
Migration design
Changing hosting with limited code changes, such as moving a compatible web app to App Service or a database to managed SQL.
Source guide: PDF page(s) 61.
Migration design
Refactoring changes code to improve cloud operation; rearchitecting changes application structure, such as decomposing a monolith.
Source guide: PDF page(s) 61.
Migration design
Replacement adopts another product or service such as SaaS; rebuilding creates a new application to meet future requirements.
Source guide: PDF page(s) 61.
Migration design
When it no longer provides business value and dependency and retention checks confirm it can be decommissioned safely.
Source guide: PDF page(s) 61.
Migration design
When keeping a stable, compliant workload in its current environment offers better near-term value than migrating it.
Source guide: PDF page(s) 61.
Migration design
Deadlines, business value, compatibility, licensing, dependencies, and team skills differ between workloads.
Source guide: PDF page(s) 61.
Migration design
Identity, subscriptions, policy, logging, security, DNS, routes, backup, and operational ownership must be stable when the workload arrives.
Source guide: PDF page(s) 61.
Migration design
A unified hub for supported discovery, assessment, planning, and migration tools and workflows.
Source guide: PDF page(s) 62.
Migration design
Discovery inventories the environment; assessment evaluates readiness and target sizing; migration copies or replicates the workload.
Source guide: PDF page(s) 62.
Migration design
Configuration and performance metadata from supported sources for discovery and assessment; its support and access requirements must be checked.
Source guide: PDF page(s) 62.
Migration design
Inventory import or other supported discovery methods, selected according to the environment and current support matrix.
Source guide: PDF page(s) 62.
Migration design
Owners, servers, identities, jobs, certificates, file shares, ports, addresses, database connections, external APIs, and licensing.
Source guide: PDF page(s) 62.
Migration design
It reveals communication between components so tightly coupled parts can move as a working application unit.
Source guide: PDF page(s) 62.
Migration design
Quiet periods can miss month-end, seasonal, or other peak demand and lead to inadequate target sizing.
Source guide: PDF page(s) 62.
Migration design
Performance-based sizing uses measured utilization; as-on-premises sizing preserves allocated capacity more directly.
Source guide: PDF page(s) 62.
Migration design
Evidence may be missing or unrepresentative; investigate before aggressively reducing capacity.
Source guide: PDF page(s) 62.
Migration design
Readiness blockers, region and SKU support, disk performance, security, monitoring, connectivity, backups, licensing, and total cost.
Source guide: PDF page(s) 62.
Migration design
It reduces final transfer volume but does not validate application consistency, identity, networking, dependencies, or production operation.
Source guide: PDF page(s) 62.
Migration design
It tests tooling, dependencies, sizing, and procedures while limiting the impact of initial mistakes.
Source guide: PDF page(s) 62.
Migration design
Prevent duplicate writers, scheduled jobs, production emails, or other real side effects while validating recovery and connectivity.
Source guide: PDF page(s) 62.
Migration design
Quiesce source writes as required, synchronize final changes, start target dependencies in order, change routes or DNS, and validate the business service.
Source guide: PDF page(s) 62-63.
Migration design
The old source lacks the new data. Rollback must reconcile or reverse-synchronize accepted writes to avoid loss or conflicting histories.
Source guide: PDF page(s) 63.
Migration design
Local disk state, configuration and secret storage, runtime support, startup behavior, authentication, backend networking, and scaling.
Source guide: PDF page(s) 63.
Migration design
When preserving a VMware environment and tooling is a justified requirement; compare it with ordinary Azure VM rehosting and long-term operations.
Source guide: PDF page(s) 63.
Migration design
Compatibility, service model, feature support, and operational requirements constrain which migration workflow is suitable.
Source guide: PDF page(s) 63.
Migration design
Server-level objects, logins, jobs, linked servers, extensions, cross-database dependencies, and application behavior.
Source guide: PDF page(s) 63.
Migration design
No. Current DMS support for Azure SQL Database is offline; online support for other SQL targets is scenario-specific.
Source guide: PDF page(s) 63.
Migration design
No. It performs initial transfer and ongoing synchronization, followed by a final synchronization and cutover outage.
Source guide: PDF page(s) 63.
Migration design
No. It consumes existing full and transaction-log backups; the source backup process, valid log chain, storage access, and final changes must be prepared.
Source guide: PDF page(s) 63.
Migration design
Yes, within the supported object list. Schema can alternatively be prepared separately with supported database project tooling.
Source guide: PDF page(s) 63.
Migration design
Critical aggregates, constraints, identities, representative transactions, execution plans, performance, and surrounding jobs.
Source guide: PDF page(s) 63.
Migration design
Azure Data Studio retired on February 28, 2026; use supported replacement tooling rather than outdated desktop-extension procedures.
Source guide: PDF page(s) 63.
Migration design
Bytes, file count and size distribution, protocol, access patterns, ACLs, timestamps, path depth, and ongoing change rate.
Source guide: PDF page(s) 64.
Migration design
Object access differs from filesystem semantics, and protocol, permissions, paths, and metadata behavior can change.
Source guide: PDF page(s) 64.
Migration design
Enumeration, metadata operations, and operations per second can bottleneck the transfer independently of byte throughput.
Source guide: PDF page(s) 64.
Migration design
Managed orchestration through projects, endpoints, job definitions, monitoring, and repeatable job runs for supported source-target paths.
Source guide: PDF page(s) 64.
Migration design
Supported protocols, cloud paths, agent requirements, preview status, metadata preservation, and target semantics differ by scenario.
Source guide: PDF page(s) 64.
Migration design
For controlled command-line copies and synchronization on supported storage paths, with appropriate authorization, logs, and content validation.
Source guide: PDF page(s) 64.
Migration design
No. Preservation depends on source, destination, supported options, and the metadata fidelity of the target.
Source guide: PDF page(s) 64.
Migration design
When a permanent Windows Server cache with cloud tiering and Azure Files is also part of the desired architecture.
Source guide: PDF page(s) 64.
Migration design
For large eligible datasets when network bandwidth or the available transfer window makes online upload impractical.
Source guide: PDF page(s) 64.
Migration design
Ordering, local copying, shipping, Azure ingestion, validation, and any final delta synchronization and cutover.
Source guide: PDF page(s) 64.
Migration design
The source may change after the bulk copy; those changes must be transferred and reconciled before switching the application.
Source guide: PDF page(s) 64.
Migration design
After business acceptance, data retention, backup validation, and rollback conditions are satisfied and the new operating model has an owner.
Source guide: PDF page(s) 64.
Migration design
Obsolete DNS records, credentials, connectivity, licenses, and unnecessary costs, in accordance with retention and rollback requirements.
Source guide: PDF page(s) 64.
Migration design
Dataset size divided by measured effective throughput, then add allowance for enumeration, retries, changed data, and validation.
Source guide: PDF page(s) 69.
Integrated architecture scenarios
A healthy frontend can coexist with a failed database; availability should reflect a meaningful business journey.
Source guide: PDF page(s) 65.
Integrated architecture scenarios
Replication lag, possible lost writes, failover authority, connection behavior, recovery-region capacity, and tested recovery time.
Source guide: PDF page(s) 65.
Integrated architecture scenarios
Availability replication can propagate deletion or corruption; older retained recovery points address a different failure.
Source guide: PDF page(s) 65.
Integrated architecture scenarios
Resolve its service name to the intended private IP, route to that address, and possess valid authentication and data authorization.
Source guide: PDF page(s) 65.
Integrated architecture scenarios
Use separate Event Hubs consumer groups with independent checkpoints and sufficient retention.
Source guide: PDF page(s) 66.
Integrated architecture scenarios
Service Bus suits business commands, Event Grid discrete notifications, and Event Hubs retained partitioned telemetry streams.
Source guide: PDF page(s) 66.
Integrated architecture scenarios
Redelivery can repeat the side effect; acknowledgement or broker duplicate detection alone does not guarantee exactly-once external business updates.
Source guide: PDF page(s) 66.
Integrated architecture scenarios
Their consistency needs and RPOs differ, so one machine-replication setting may not meet every dependency's recovery requirement.
Source guide: PDF page(s) 66.
Integrated architecture scenarios
Network paths, DNS, identity services, permissions, and other dependency prerequisites.
Source guide: PDF page(s) 66.
Integrated architecture scenarios
The sequence totals 45 minutes, leaving 15 minutes. All steps and assumptions must be measured under representative failure conditions.
Source guide: PDF page(s) 68.
Integrated architecture scenarios
No. Validate lag under load and outages and identify the latest usable consistent recovery point for all dependencies.
Source guide: PDF page(s) 68.
Integrated architecture scenarios
Validated identity, authorization, transactions, performance, connectivity, monitoring, backup, and rollback readiness against agreed acceptance criteria.
Source guide: PDF page(s) 69.
These are original study questions. Multiple-response practice uses exact-set scoring in the app, with no partial credit.
Architecture foundations and design method · Migration design
✓ Correct answer
CAF connects adoption readiness and shared foundations; WAF reviews workload quality through its pillars. Reversing their roles misses this distinction. Monitor and Policy are useful implementation services rather than substitutes for architecture frameworks. CAF alone does not replace a workload quality review. Source guide: PDF page(s) 4-5.
This item is flagged for content review.
Open this question’s page →Architecture foundations and design method
✓ Correct answer
Measurable objectives guide the actual design and testing. VM counts follow capacity and failure analysis, region choice also depends on constraints, and component SLAs do not define the end-to-end journey. Source guide: PDF page(s) 4.
This item is flagged for content review.
Open this question’s page →Architecture foundations and design method
✓ Correct answer
Managed hosting reduces maintenance when its capabilities meet requirements. The customer still owns application permissions, data governance, and relevant recovery settings. None of those duties disappears merely because the service is PaaS. Source guide: PDF page(s) 4.
This item is flagged for content review.
Open this question’s page →Architecture foundations and design method
✓ Correct answer
Plan prepares skills, costs, priorities, ownership, and adoption work. Ready establishes the Azure foundation; Adopt executes migration and modernization; Manage operates and improves adopted workloads. Source guide: PDF page(s) 4.
This item is flagged for content review.
Open this question’s page →Architecture foundations and design method · Migration design
✓ Correct answers
Shared platform responsibilities and application responsibilities must both be assigned. Microsoft does not own every customer runbook; subscription placement supplies no universal failover; a landing zone is an architecture and operating foundation rather than one service. Source guide: PDF page(s) 4-5.
This item is flagged for content review.
Open this question’s page →Architecture foundations and design method
✓ Correct answer
Operational Excellence addresses controlled deployment, automation, observability, and operations. Performance focuses on user experience and bottlenecks; Cost focuses on value and spending; Reliability is related but does not replace the operating practices needed here. Source guide: PDF page(s) 5.
This item is flagged for content review.
Open this question’s page →Architecture foundations and design method · High availability
✓ Correct answers
The design must meet recovery objectives and account for additional spending and operations. Replication mechanisms vary, replicated copies do not replace retained recovery points, and ownership remains shared. Source guide: PDF page(s) 5.
This item is flagged for content review.
Open this question’s page →Architecture foundations and design method · Network design
✓ Correct answer
A regional subnet normally spans zones, so zone placement alone does not require new subnets. Separate VNets are not mandatory, zones are not regions, and a subnet does not replicate a VM. Source guide: PDF page(s) 6.
This item is flagged for content review.
Open this question’s page →Architecture foundations and design method
✓ Correct answer
Logical zone labels are subscription-specific mappings. Names, tags, and management-group placement do not prove physical-zone correspondence. Source guide: PDF page(s) 6.
This item is flagged for content review.
Open this question’s page →Architecture foundations and design method · Backup and disaster recovery
✓ Correct answer
A region pair supplies no automatic application recovery. The application needs configured replication and recovery paths. Resource names, grouping, and logical-zone labels do not supply those mechanisms. Source guide: PDF page(s) 6.
This item is flagged for content review.
Open this question’s page →Architecture foundations and design method · Object, file, and NoSQL data
✓ Correct answer
Residency must be checked per service and actual destination. Some regions are unpaired and service replication choices vary; pair relationships have exceptions and can be asymmetric. Zones address a different failure boundary. Source guide: PDF page(s) 6.
This item is flagged for content review.
Open this question’s page →Architecture foundations and design method
✓ Correct answers
PaaS retains customer duties for applications, data, permissions, and configuration. Physical infrastructure and underlying host maintenance belong to the provider within the service model. Source guide: PDF page(s) 6.
This item is flagged for content review.
Open this question’s page →Architecture foundations and design method
✓ Correct answer
Contracts have distinct definitions and conditions; real dependencies can fail together. User-journey measurement and end-to-end analysis are required. Multiplication can illustrate an explicit independent model but establishes no composite contractual guarantee; maximum or summed values are also invalid. Source guide: PDF page(s) 7.
This item is flagged for content review.
Open this question’s page →Architecture foundations and design method
✓ Correct answer
For the stated independent serial model, 0.999 × 0.999 = 0.998001, or 99.8001%. The other values do not follow this multiplication. The calculation is mathematical intuition and does not establish a contractual SLA or realistic workload estimate. Source guide: PDF page(s) 7.
This item is flagged for content review.
Open this question’s page →Architecture foundations and design method
✓ Correct answer
Total operating cost includes normal, peak, and recovery operation and supporting services and labor. Adding one VM omits dependencies; recovery costs are part of planning; a discount alone does not describe value or total cost. Source guide: PDF page(s) 7.
This item is flagged for content review.
Open this question’s page →Monitoring and logging
✓ Correct answer
Customer-journey and dependency signals reveal the failed outcome and its cause. CPU can remain low during a dependency outage. Activity logs describe management events rather than the whole transaction. Azure Status reports the global platform and cannot prove application health. Source: AZ-305 Study Guide.pdf, PDF page(s) 8.
This item is flagged for content review.
Open this question’s page →Monitoring and logging
✓ Correct answer
AMA and DCR associations collect supported guest events, while resource diagnostic settings collect Key Vault audits. An agent does not configure a vault's diagnostic logs; a vault setting does not collect guest events. Creating the destination alone does not initiate either collection path. Source: AZ-305 Study Guide.pdf, PDF page(s) 8.
This item is flagged for content review.
Open this question’s page →Monitoring and logging
✓ Correct answer
Distributed traces connect the individual request to dependency spans and their durations. Host CPU averages cannot attribute one transaction's latency. Locks control supported management operations. Activity logs record management events and do not replace request instrumentation. Source: AZ-305 Study Guide.pdf, PDF page(s) 8.
This item is flagged for content review.
Open this question’s page →Monitoring and logging
✓ Correct answer
Event Hubs is the diagnostic streaming destination for external consumers such as a SIEM. A Prometheus workspace is a metrics store. A DCR association does not itself configure resource-log streaming. Action groups respond to alert conditions rather than providing a general continuous resource-log export. Source: AZ-305 Study Guide.pdf, PDF page(s) 9.
This item is flagged for content review.
Open this question’s page →Monitoring and logging
✓ Correct answers
Log Analytics provides interactive log queries; immutable Storage supplies an independently protected archive. Webhooks are alert-response endpoints, a Prometheus workspace stores metrics, and Resource Health reports resource health. None of those three replaces the required audit archive or KQL log destination. Source: AZ-305 Study Guide.pdf, PDF page(s) 9.
This item is flagged for content review.
Open this question’s page →Monitoring and logging
✓ Correct answer
Storage and Event Hubs diagnostic destinations must match the region of a regional monitored resource. Log Analytics has no equivalent destination-region restriction. A private endpoint does not waive this requirement, and a resource group's metadata location does not relocate its contained resource. Source: AZ-305 Study Guide.pdf, PDF page(s) 9.
This item is flagged for content review.
Open this question’s page →Monitoring and logging
✓ Correct answer
One diagnostic setting supports one destination of each type, so two workspace destinations need separate settings. A resource supports up to five settings, making six invalid. A DCE is connectivity for supported DCR paths and does not alter diagnostic-setting destination limits. Source: AZ-305 Study Guide.pdf, PDF page(s) 9.
This item is flagged for content review.
Open this question’s page →Monitoring and logging
✓ Correct answer
The documented diagnostic export path requires the trusted Microsoft services bypass for firewall-protected Event Hubs. A private endpoint alone does not redirect this path. A VM DCR is a separate collection mechanism. A different region does not solve the firewall condition and can violate regional destination rules. Source: AZ-305 Study Guide.pdf, PDF page(s) 9.
This item is flagged for content review.
Open this question’s page →Monitoring and logging
✓ Correct answers
Cross-subscription routing is supported when the configuring identity has relevant permissions. Regional Storage and Event Hubs restrictions still apply. A shared subscription is not mandatory, Log Analytics lacks that region restriction, and a private endpoint does not remove export requirements. Source: AZ-305 Study Guide.pdf, PDF page(s) 9.
This item is flagged for content review.
Open this question’s page →Monitoring and logging
✓ Correct answer
AMA uses reusable DCR-based collection; Arc represents supported external servers and enables agent deployment. MMA is retired and is unsuitable for a new design. Resource-group diagnostic settings do not substitute for guest collection. Application instrumentation measures the application and does not collect all required Windows events. Source: AZ-305 Study Guide.pdf, PDF page(s) 10.
This item is flagged for content review.
Open this question’s page →Monitoring and logging
✓ Correct answers
Reuse makes matching collection consistent, and separate rules preserve meaningful collection or security boundaries. A universal rule ignores different requirements. A DCE provides connectivity rather than collection policy. Validation should generate representative events and confirm destination arrival, rather than check only resource existence. Source: AZ-305 Study Guide.pdf, PDF page(s) 10.
This item is flagged for content review.
Open this question’s page →Monitoring and logging
✓ Correct answer
A DCE provides configuration and ingestion endpoints for relevant scenarios and is not universally required. A DCR defines collection policy. Diagnostic settings and application instrumentation are distinct paths, so the claim that a VM DCE controls Key Vault export must also be removed. Source: AZ-305 Study Guide.pdf, PDF page(s) 10.
This item is flagged for content review.
Open this question’s page →Monitoring and logging
✓ Correct answer
Supported transformations reduce volume and exposure, but discarded data cannot be recovered from that collection path. Requirements must therefore be agreed first. A hard cap can remove incident evidence, and DCR collection does not replace separate application instrumentation or resource diagnostic settings. Source: AZ-305 Study Guide.pdf, PDF page(s) 10.
This item is flagged for content review.
Open this question’s page →Monitoring and logging
✓ Correct answer
A shared workspace simplifies correlation and administration when boundaries align. Subscription count alone does not require separate workspaces. Per-VM workspaces fragment queries. Unconditional duplication can double ingestion and should be justified against isolation, access, and Sentinel requirements. Source: AZ-305 Study Guide.pdf, PDF page(s) 10.
This item is flagged for content review.
Open this question’s page →Monitoring and logging
✓ Correct answer
Real tenant, residency, or access boundaries justify separate workspaces despite centralization benefits. A mandatory single workspace would ignore those requirements. Per-resource-group separation is arbitrary, and tags are metadata rather than a log authorization boundary. Source: AZ-305 Study Guide.pdf, PDF page(s) 10.
This item is flagged for content review.
Open this question’s page →Monitoring and logging
✓ Correct answer
Analytics supports the requested operational features. Basic supports Simple Log Alerts but lacks Insights and resource-context queries; Auxiliary also lacks Insights and direct alerts. Retention duration and workspace access configuration do not add missing table-plan capabilities. Source: AZ-305 Study Guide.pdf, PDF page(s) 10-11.
This item is flagged for content review.
Open this question’s page →Monitoring and logging
✓ Correct answer
Plans are selected per supported table, letting critical signals retain Analytics features while infrequent diagnostics use another plan. There is no single workspace-wide plan switch for all records. Auxiliary lacks direct alert and Insights support, and Basic/Auxiliary query scanning incurs charges. Source: AZ-305 Study Guide.pdf, PDF page(s) 10-11.
This item is flagged for content review.
Open this question’s page →Monitoring and logging
✓ Correct answers
Analytics retention and total retention serve different access periods, and both can be configured to meet these durations within documented limits. Total retention does not grant every plan identical interactive features. Basic directly queries 30 days, while total retention can extend to 12 years rather than only two. Source: AZ-305 Study Guide.pdf, PDF page(s) 11.
This item is flagged for content review.
Open this question’s page →Monitoring and logging
✓ Correct answer
Search jobs can retrieve retained Basic data beyond its 30-day direct-query window and create Analytics results asynchronously. The direct window does not equal total retention and cannot simply be extended to eight months as Basic's regular query window. A new resource diagnostic setting exports supported source telemetry; it does not retrieve historical workspace data. Source: AZ-305 Study Guide.pdf, PDF page(s) 11.
This item is flagged for content review.
Open this question’s page →Monitoring and logging
✓ Correct answer
Basic and Auxiliary charge for queries, so frequent scanning can dominate economics. Evaluate access frequency, scanned volume, retention, and plan features. An ingestion commitment tier does not itself explain or eliminate query-scanning costs. Auxiliary queries are not free merely because ingestion is cheaper. Source: AZ-305 Study Guide.pdf, PDF page(s) 11.
This item is flagged for content review.
Open this question’s page →Monitoring and logging
✓ Correct answer
Controlling unnecessary sources and transforming supported streams can reduce cost while preserving essential signals. A lower cap or disabling monitoring worsens the evidence gap. Logs discarded or never ingested through that path cannot be reconstructed from the workspace. Source: AZ-305 Study Guide.pdf, PDF page(s) 11.
This item is flagged for content review.
Open this question’s page →Monitoring and logging
✓ Correct answers
Correlation enables a transaction to be followed across services, and sampling must be evaluated against diagnostic evidence needs. Sampling affects available detail. Activity logs are management records rather than request spans, and secrets should not be included in telemetry. Source: AZ-305 Study Guide.pdf, PDF page(s) 11.
This item is flagged for content review.
Open this question’s page →Monitoring and logging
✓ Correct answer
Application Insights and workspace query contexts can expose different schemas, so adapt both table and field names as required and retain a useful time restriction. Agent reinstallation does not fix schema mismatch. Case changes alone do not address a different table, and workspace queries support time filtering. Source: AZ-305 Study Guide.pdf, PDF page(s) 11.
This item is flagged for content review.
Open this question’s page →Monitoring and logging
✓ Correct answers
Container Insights logs use Log Analytics, while managed Prometheus uses the distinct Azure Monitor workspace. A Log Analytics workspace does not replace that managed metrics store. Application Insights supplies application observability rather than both specified platform stores, and Event Hubs is a stream destination rather than either managed investigation store. Source: AZ-305 Study Guide.pdf, PDF page(s) 12.
This item is flagged for content review.
Open this question’s page →Monitoring and logging
✓ Correct answer
Application tracing connects service requests and dependencies, exposing failures beyond cluster-level metrics. CPU resolution and management events do not establish each application's transaction path. Managed Prometheus cluster metrics are useful but cannot replace tracing for this requirement. Source: AZ-305 Study Guide.pdf, PDF page(s) 12.
This item is flagged for content review.
Open this question’s page →Monitoring and logging
✓ Correct answer
Metric alerts evaluate numeric time-series signals, with supported thresholds and dimensions. Resource-deletion alerts detect different management events. Policy exemptions and employee lifecycle workflows do not monitor sustained queue-depth behavior. Source: AZ-305 Study Guide.pdf, PDF page(s) 12.
This item is flagged for content review.
Open this question’s page →Monitoring and logging
✓ Correct answers
The log alert evaluates the required record pattern or aggregation; the action group supplies reusable notification or automation destinations. Activity-log alerts address supported management events. DCEs are collection endpoints and locks govern supported management operations rather than query evaluation or response routing. Source: AZ-305 Study Guide.pdf, PDF page(s) 12.
This item is flagged for content review.
Open this question’s page →Monitoring and logging
✓ Correct answer
Service Health provides personalized provider incidents, maintenance, and advisories for relevant services and regions. Azure Status is the public global view; Resource Health focuses on individual resources. Application exceptions help diagnose the workload but do not replace provider maintenance notifications. Source: AZ-305 Study Guide.pdf, PDF page(s) 12.
This item is flagged for content review.
Open this question’s page →Monitoring and logging
✓ Correct answer
Actionable monitoring needs a responsible owner and a usable, tested response path, including accessible runbooks during failures. More frequent detection does not fix escalation. Testing only condition evaluation omits delivery and responder access, and the failed application cannot be the sole host of required response instructions. Source: AZ-305 Study Guide.pdf, PDF page(s) 12.
This item is flagged for content review.
Open this question’s page →Monitoring and logging
✓ Correct answer
Activity-log alerts detect supported management events, and action groups route their response. CPU does not reliably identify configuration changes; application sampling controls application telemetry rather than management auditing. A table plan determines storage and query capabilities but does not collect or detect an event on its own. Source: AZ-305 Study Guide.pdf, PDF page(s) 8, 12.
This item is flagged for content review.
Open this question’s page →Identity and access
✓ Correct answer
PHS validates synchronized derived hashes in the cloud without a per-sign-in local request. The proposed PTA and AD FS designs still depend on the unavailable site. Cloud Sync provisions directory information; selecting its synchronization architecture alone does not establish an outage-resilient authentication method. Source: AZ-305 Study Guide.pdf, PDF page(s) 13-14.
This item is flagged for content review.
Open this question’s page →Identity and access
✓ Correct answer
PHS validates in the cloud, and relevant account-state changes depend on synchronization. It does not query current AD state for each sign-in or immediately remove the cloud identity without synchronization. Incident response must also consider cloud accounts and sessions rather than assume that all tokens are instantly revoked. Source: AZ-305 Study Guide.pdf, PDF page(s) 14.
This item is flagged for content review.
Open this question’s page →Identity and access
✓ Correct answer
PTA validates passwords through outbound-connected agents against AD DS. PHS validates cloud information, and a cloud-only identity does not directly validate the specified AD policies. Cloud Sync handles provisioning rather than being the password-validation selection itself. Source: AZ-305 Study Guide.pdf, PDF page(s) 13-14.
This item is flagged for content review.
Open this question’s page →Identity and access
✓ Correct answers
PTA requires resilient agents and reachable domain controllers; three agents are recommended. PHS backup can be enabled, but switching to it is a planned manual change. One agent is still a dependency, and adding agents alone does not eliminate shared domain-controller or network failure. Source: AZ-305 Study Guide.pdf, PDF page(s) 14.
This item is flagged for content review.
Open this question’s page →Identity and access
✓ Correct answer
An existing AD DS forest does not require federation. Cloud authentication can reduce validation-path infrastructure when native capabilities meet the requirement. Application protocol support must be assessed rather than assuming every SAML app requires AD FS, and synchronization does not force federation. Source: AZ-305 Study Guide.pdf, PDF page(s) 14.
This item is flagged for content review.
Open this question’s page →Identity and access
✓ Correct answers
Staged rollout permits incremental validation, and prepared emergency alternatives make recovery concrete. Premature certificate deletion can break remaining federation. Authentication dependencies and certificate expiry affect availability, and an untested universal cutover can expose compatibility problems. Source: AZ-305 Study Guide.pdf, PDF page(s) 14.
This item is flagged for content review.
Open this question’s page →Identity and access
✓ Correct answer
Conditional Access evaluates supported sign-in signals and applies the required authentication conditions. Azure resource roles authorize operations, and allowed-locations Policy governs resource deployment rather than the user's sign-in location. PIM reduces standing privilege but does not replace targeted sign-in conditions. Source: AZ-305 Study Guide.pdf, PDF page(s) 14.
This item is flagged for content review.
Open this question’s page →Identity and access
✓ Correct answer
Method strength matters, so select supported methods meeting the stated assurance and plan recovery. MFA methods differ in phishing resistance. Narrow authorization does not satisfy the authentication requirement, and report-only measures impact without enforcing the access condition. Source: AZ-305 Study Guide.pdf, PDF page(s) 14.
This item is flagged for content review.
Open this question’s page →Identity and access
✓ Correct answers
Report-only and staged rollout identify unintended blocking, while tested emergency access supports recovery. Conditional Access does not grant application data permissions. Unrecoverable lockout is unsuitable, and licensing varies by feature, with additional requirements for risk-based controls. Source: AZ-305 Study Guide.pdf, PDF page(s) 14.
This item is flagged for content review.
Open this question’s page →Identity and access
✓ Correct answer
The synchronization architectures and evolving capabilities should be compared against the actual requirements. Provisioning is separate from credential validation, so Cloud Sync does not automatically choose federation. Agent footprint matters but cannot substitute for required feature and availability support. Source: AZ-305 Study Guide.pdf, PDF page(s) 13.
This item is flagged for content review.
Open this question’s page →Identity and access
✓ Correct answer
The application registration defines identity and configuration, while service principals provide tenant-specific application representations. Registrations are not necessarily human users, and the two concepts are not one universal cross-tenant object. Neither is a subscription or an individual access token. Source: AZ-305 Study Guide.pdf, PDF page(s) 13.
This item is flagged for content review.
Open this question’s page →Identity and access
✓ Correct answer
B2B collaboration suits partner access to workforce resources with existing external identities. A customer tenant addresses a different primary population and is not by itself integration to the workforce resources. Separate passwords conflict with the stated preference, and invitations still need authorization and lifecycle controls. Source: AZ-305 Study Guide.pdf, PDF page(s) 14-15.
This item is flagged for content review.
Open this question’s page →Identity and access
✓ Correct answer
An external tenant provides an appropriate customer sign-up/sign-in experience separated from employee resources. Workforce guest or employee accounts address other populations and do not fit the stated tenant separation. Service principals represent workloads, not a complete end-customer identity architecture. Source: AZ-305 Study Guide.pdf, PDF page(s) 14-15.
This item is flagged for content review.
Open this question’s page →Identity and access
✓ Correct answer
User-assigned identity is a separate resource and can retain its principal across compute replacement or exist before compute. System-assigned identities share compute lifecycle. A long-lived secret adds credential management unnecessarily, and unreviewed identity sharing combines effective privileges across workloads. Source: AZ-305 Study Guide.pdf, PDF page(s) 15.
This item is flagged for content review.
Open this question’s page →Identity and access
✓ Correct answer
System-assigned identity fits this resource's lifecycle and avoids application-owned secrets, but target authorization remains necessary. Unnecessary identity sharing can combine privileges, while a stored client secret adds credential-management burden. Managed identity enablement alone does not grant target access. Source: AZ-305 Study Guide.pdf, PDF page(s) 15.
This item is flagged for content review.
Open this question’s page →Identity and access
✓ Correct answers
Federation exchanges a matching trusted external token, while authorization remains a separate least-privilege grant. Unrestricted issuer or subject trust broadens impersonation opportunities. Human passwords are not a substitute for the configured token trust, and exchange does not automatically grant Owner. Source: AZ-305 Study Guide.pdf, PDF page(s) 15.
This item is flagged for content review.
Open this question’s page →Identity and access
✓ Correct answer
A role such as Storage Blob Data Reader grants the required data operation. Repeating management Reader adds no blob permission. Contributor may permit broader management or indirect data access but is excessive for this read-only requirement. MFA improves sign-in assurance rather than granting blob rights. Source: AZ-305 Study Guide.pdf, PDF page(s) 15-16.
This item is flagged for content review.
Open this question’s page →Identity and access
✓ Correct answer
Contributor manages resources without the standard role-assignment capability; Owner includes access management. Reader lacks resource-management privileges. Global Administrator governs the Entra directory and is not an interchangeable Azure resource role. Evaluate indirect data-access pathways separately. Source: AZ-305 Study Guide.pdf, PDF page(s) 15.
This item is flagged for content review.
Open this question’s page →Identity and access
✓ Correct answer
RBAC combines applicable direct, group, and inherited assignments. A narrow role adds a grant rather than replacing a broader one. Assignment recency does not select a single winning role, and group grants participate in effective access. Source: AZ-305 Study Guide.pdf, PDF page(s) 15-16.
This item is flagged for content review.
Open this question’s page →Identity and access
✓ Correct answer
NotActions subtracts from the permissions of that role definition, while another applicable role can still grant the operation. It is not a universal denial. Custom roles have no blanket precedence over built-ins, and role-name order is irrelevant to authorization. Source: AZ-305 Study Guide.pdf, PDF page(s) 16.
This item is flagged for content review.
Open this question’s page →Identity and access
✓ Correct answer
Conditions refine their own supported role assignments; an unconditional grant may still authorize access. Enforce the intent through the complete effective-access set. Cost-center tags alone are metadata, and Reader is an additive management grant rather than an explicit data denial. Source: AZ-305 Study Guide.pdf, PDF page(s) 16.
This item is flagged for content review.
Open this question’s page →Identity and access
✓ Correct answers
Managed identity provides authentication, but the vault must authorize the operation and the service must be reachable with the correct token audience. Owner is excessive for one secret, identity does not bypass network policy, and tags are unsuitable plaintext secret storage. Source: AZ-305 Study Guide.pdf, PDF page(s) 15.
This item is flagged for content review.
Open this question’s page →Identity and access
✓ Correct answers
Separation requires checking explicit data operations and indirect management pathways. Effective access includes applicable group and inherited assignments. Some management permissions enable data access through keys or configuration, and management locks do not replace service data authorization. Source: AZ-305 Study Guide.pdf, PDF page(s) 16.
This item is flagged for content review.
Open this question’s page →Identity and access
✓ Correct answer
Directory administration and Azure resource authorization target different systems and require separate role decisions. Global Administrator is not automatically interchangeable with subscription Owner. Workload directory-admin grants are excessive, and tags do not authorize administration. Source: AZ-305 Study Guide.pdf, PDF page(s) 13.
This item is flagged for content review.
Open this question’s page →Identity and access
✓ Correct answer
Entra Domain Services provides the listed managed legacy capabilities for supported workloads. Entra ID alone is not a direct LDAP/Kerberos domain service. Self-managed domain controllers retain customer operational responsibilities, and application proxy publishes supported web applications rather than supplying domain join or Group Policy. Source: AZ-305 Study Guide.pdf, PDF page(s) 16.
This item is flagged for content review.
Open this question’s page →Identity and access
✓ Correct answers
Application proxy provides the web publishing/preauthentication path, and configured KCD enables integrated Windows SSO for the permitted service. It is not general VPN connectivity. Azure Reader does not supply Kerberos application authorization, and internal app permissions remain necessary. Source: AZ-305 Study Guide.pdf, PDF page(s) 16.
This item is flagged for content review.
Open this question’s page →Identity and access
✓ Correct answer
Cloud Kerberos trust fits the supported passwordless-client SSO scenario while on-premises domain controllers still issue service tickets and control authorization. Connectivity remains necessary. Application proxy is supported web publishing, and Entra Domain Services is a different managed legacy-domain scenario rather than a mandatory replacement. Source: AZ-305 Study Guide.pdf, PDF page(s) 16.
This item is flagged for content review.
Open this question’s page →Identity and access
✓ Correct answer
Traditional file-share access requires the supported AD authentication and group/ACL authorization path along with connectivity and DNS. Subscription roles do not override share ACLs, and successful sign-in does not automatically add access groups. Application proxy publishes supported web apps rather than supplying general SMB authorization. Source: AZ-305 Study Guide.pdf, PDF page(s) 16.
This item is flagged for content review.
Open this question’s page →Identity and access
✓ Correct answer
A secret stores a retrievable sensitive API credential. A cryptographic key performs supported operations rather than serving as arbitrary password-value storage. A certificate object manages X.509 material, and Managed HSM supports keys rather than general secret objects. Source: AZ-305 Study Guide.pdf, PDF page(s) 16-17.
This item is flagged for content review.
Open this question’s page →Identity and access
✓ Correct answer
Managed HSM is the dedicated single-tenant key service using documented FIPS 140-3 Level 3 validated HSMs. Premium vault HSM keys are a different offering and do not establish identical dedicated tenancy. Standard software keys and a certificate object do not supply the required dedicated HSM custody. Source: AZ-305 Study Guide.pdf, PDF page(s) 17.
This item is flagged for content review.
Open this question’s page →Identity and access
✓ Correct answer
Azure RBAC supports separation through distinct management and data roles, such as Key Vault Secrets User for suitable secret retrieval. Owner and shared administrator credentials are excessive. Contributor is a management role and is not a universal guarantee of secret retrieval; indirect escalation paths must also be controlled. Source: AZ-305 Study Guide.pdf, PDF page(s) 17.
This item is flagged for content review.
Open this question’s page →Identity and access
✓ Correct answers
Soft delete retains recoverable objects, and purge protection blocks permanent deletion before the retention period ends. Tags do not provide recovery. Immediate purge undermines the requirement, and management locks do not replace object recovery controls or the availability of required key versions. Source: AZ-305 Study Guide.pdf, PDF page(s) 17.
This item is flagged for content review.
Open this question’s page →Identity and access
✓ Correct answer
Rotation must coordinate consumer version adoption and preservation of keys required by existing data or recovery. Creating a version does not automatically re-encrypt every external dataset. Immediate disablement can make data unavailable, and plaintext tags are unsuitable for private key material. Source: AZ-305 Study Guide.pdf, PDF page(s) 17.
This item is flagged for content review.
Open this question’s page →Identity and access
✓ Correct answer
A secret version is a stored value, so a rotation workflow must also change the external password and update consumers in a safe sequence. It does not automatically change external systems. Secrets differ from cryptographic keys, and Managed HSM is not general password storage or universal database rotation. Source: AZ-305 Study Guide.pdf, PDF page(s) 17.
This item is flagged for content review.
Open this question’s page →Identity and access
✓ Correct answer
Certificate lifecycle includes consuming-service adoption as well as vault renewal, so verify refresh and transition behavior. Renewal does not guarantee universal immediate reload. Tags do not supply certificate material, and removing audits does not solve adoption or provide visibility into expiry. Source: AZ-305 Study Guide.pdf, PDF page(s) 17.
This item is flagged for content review.
Open this question’s page →Identity and access
✓ Correct answer
From API version 2026-02-01, newly created vaults default to Azure RBAC. This does not automatically convert every existing vault or grant all managed identities data access. Explicit suitable role assignments and deployment-model checks remain necessary. Source: AZ-305 Study Guide.pdf, PDF page(s) 17.
This item is flagged for content review.
Open this question’s page →Governance and compliance
✓ Correct answer
Management groups provide governance scopes above subscriptions, allowing applicable policy and roles to inherit. Resource groups contain resources rather than subscriptions. An assignment on one subscription does not inherit to siblings, and a workspace is a telemetry container rather than a governance parent. Source: AZ-305 Study Guide.pdf, PDF page(s) 18.
This item is flagged for content review.
Open this question’s page →Governance and compliance
✓ Correct answer
The supported depth is six management-group levels excluding root and subscription, and durable policy needs should drive a understandable hierarchy. Organizational reporting lines and placement of leaf subscriptions do not override the limit. Tags do not replace inherited evaluated policy. Source: AZ-305 Study Guide.pdf, PDF page(s) 18.
This item is flagged for content review.
Open this question’s page →Governance and compliance
✓ Correct answer
Applicable parent assignments inherit, so restrict broad scope and role grants to enforce the desired production boundary. Separate subscriptions do not cancel inherited roles. Tags do not modify authorization, and subscriptions do not belong inside resource groups. Source: AZ-305 Study Guide.pdf, PDF page(s) 18.
This item is flagged for content review.
Open this question’s page →Governance and compliance
✓ Correct answers
Subscriptions provide concrete administrative, billing, quota, environment, and governance boundaries. Geography alone need not define a management-group boundary. Separation does not eliminate inherited privilege, and resource groups cannot contain subscriptions. Source: AZ-305 Study Guide.pdf, PDF page(s) 18.
This item is flagged for content review.
Open this question’s page →Governance and compliance
✓ Correct answer
Lifecycle and ownership grouping lets temporary deletion avoid long-lived data resources. Deleting a resource group initiates deletion of contained resources. Groups cannot nest, and group deletion is not merely metadata deletion. Source: AZ-305 Study Guide.pdf, PDF page(s) 19.
This item is flagged for content review.
Open this question’s page →Governance and compliance
✓ Correct answers
Resource-group location concerns metadata, and resources can be deployed in multiple regions within the same group. Ordinary resource-group-scoped resources belong to one group at a time; groups cannot nest. Regional service requirements still apply independently of this grouping choice. Source: AZ-305 Study Guide.pdf, PDF page(s) 19.
This item is flagged for content review.
Open this question’s page →Governance and compliance
✓ Correct answer
Tags do not automatically inherit; suitable modify policies can copy approved parent values, with required remediation for existing resources. Management groups do not support tags. Tags support reporting and automation but do not grant or restrict resource access themselves. Source: AZ-305 Study Guide.pdf, PDF page(s) 19.
This item is flagged for content review.
Open this question’s page →Governance and compliance
✓ Correct answers
Stable identifiers and accountable groups improve ownership continuity. Tags are plaintext, so keep secrets/personal data out and standardize casing because values are case-sensitive. Temporary individual names become stale, a compliance claim is not evaluated evidence, and inconsistent value casing can fragment reporting. Source: AZ-305 Study Guide.pdf, PDF page(s) 19.
This item is flagged for content review.
Open this question’s page →Governance and compliance
✓ Correct answer
RBAC and Policy answer different questions: permission to perform the operation and applicable configuration constraints. Contributor does not bypass a deny policy. Audit records noncompliance without blocking, and a cost-center tag alone is not the complete authorization or compliance mechanism. Source: AZ-305 Study Guide.pdf, PDF page(s) 19.
This item is flagged for content review.
Open this question’s page →Governance and compliance
✓ Correct answer
Audit reports noncompliance without blocking or repairing. Deny blocks violating operations. DeployIfNotExists can deploy supported related configuration, and modify changes supported properties; neither is a universal observation-only substitute. Source: AZ-305 Study Guide.pdf, PDF page(s) 19.
This item is flagged for content review.
Open this question’s page →Governance and compliance
✓ Correct answers
DeployIfNotExists can create related configuration using the assignment identity, and existing findings need remediation tasks. A compliance scan reports state rather than automatically repairing every existing resource. Audit does not deploy, and remediation needs the actual permissions to create the settings. Source: AZ-305 Study Guide.pdf, PDF page(s) 19-20.
This item is flagged for content review.
Open this question’s page →Governance and compliance
✓ Correct answer
The assignment identity performs supported remediation and needs roles for the new actions; definition changes do not automatically update its permissions. The report reader is not necessarily the remediation principal. Audit identifies noncompliance but does not perform the required property changes. Source: AZ-305 Study Guide.pdf, PDF page(s) 20.
This item is flagged for content review.
Open this question’s page →Governance and compliance
✓ Correct answer
An exemption records an accepted exception against an assignment and can preserve its governance context with expiry. An exclusion removes scope from evaluation and the proposed broad untracked exclusion loses accountability. Locks do not prove policy compliance, and deleting the common baseline is excessive. Source: AZ-305 Study Guide.pdf, PDF page(s) 20.
This item is flagged for content review.
Open this question’s page →Governance and compliance
✓ Correct answer
Machine Configuration evaluates or applies supported guest settings using its prerequisites and packages. ARM region/size does not prove OS configuration. General posture findings do not remove required guest-package/assignment planning, and log collection through AMA is a separate telemetry mechanism rather than universal guest-configuration enforcement. Source: AZ-305 Study Guide.pdf, PDF page(s) 20.
This item is flagged for content review.
Open this question’s page →Governance and compliance
✓ Correct answers
Defender for Cloud supplies posture and supported compliance assessments, while Sentinel supplies security-event correlation and incident workflows. Azure Monitor supports observability rather than legal certification. Policy evaluates supported resource controls and does not replace all incident investigation; access reviews recertify identity access rather than function as a general SIEM. Source: AZ-305 Study Guide.pdf, PDF page(s) 20.
This item is flagged for content review.
Open this question’s page →Governance and compliance
✓ Correct answer
Blueprints is already in phased retirement; current guidance recommends deployment stacks and template specs for relevant lifecycle and reusable-template needs. New blueprint definitions and versions ceased July 31, 2026. Retirement does not make supported infrastructure-as-code templates unavailable. Source: AZ-305 Study Guide.pdf, PDF page(s) 20.
This item is flagged for content review.
Open this question’s page →Governance and compliance
✓ Correct answers
Unexported blueprint metadata is deleted at final retirement and blueprint locks stop functioning, while resources created through blueprints remain. Therefore preserve needed definitions and replace required protection. Workloads are not automatically deleted, locks do not remain indefinitely, and definition creation already ceased during the phased schedule. Source: AZ-305 Study Guide.pdf, PDF page(s) 20.
This item is flagged for content review.
Open this question’s page →Governance and compliance
✓ Correct answer
Lifecycle design needs authoritative attributes, automated supported tasks/provisioning, and decisions about access through role changes and departure. Synchronization aligns directories but does not replace governance. Retaining obsolete enabled access conflicts with the leaver process, and resource groups are Azure resource containers. Source: AZ-305 Study Guide.pdf, PDF page(s) 20-21.
This item is flagged for content review.
Open this question’s page →Governance and compliance
✓ Correct answer
PIM eligibility and configured activation controls reduce standing privileged duration. Permanent Owner remains standing privilege even with reviews or MFA. Access packages govern approved access bundles and policies rather than replacing all PIM activation mechanics. Source: AZ-305 Study Guide.pdf, PDF page(s) 21.
This item is flagged for content review.
Open this question’s page →Governance and compliance
✓ Correct answer
PIM reduces duration of privilege, not the active role's permission set. Scope, role selection, monitoring, and eligibility reviews still matter. MFA improves sign-in assurance but does not make all actions compliant or remove applicable policy constraints. Source: AZ-305 Study Guide.pdf, PDF page(s) 21.
This item is flagged for content review.
Open this question’s page →Governance and compliance
✓ Correct answer
Access packages combine supported resources with request, approval, expiry, and review policies. Permanent manual grants omit enforced lifecycle requirements. A single privileged-role activation does not supply the project bundle, and a review alone does not implement the complete approved request and expiry design. Source: AZ-305 Study Guide.pdf, PDF page(s) 21.
This item is flagged for content review.
Open this question’s page →Governance and compliance
✓ Correct answer
Supported group membership can provide the indirect authorization path to a resource already using that group, but its role and effective access must be verified. Access packages do not directly package every possible Azure permission or automatically override resource authorization. Expiry must apply to actual access. Source: AZ-305 Study Guide.pdf, PDF page(s) 21.
This item is flagged for content review.
Open this question’s page →Governance and compliance
✓ Correct answers
Access reviews need decisions applied to their defined scope, and separate grants can still authorize access. Verify effective access after removal. A review is not a universal permission purge, a tag does not revoke authorization, and alternate grants call for improved review scope rather than abandonment. Source: AZ-305 Study Guide.pdf, PDF page(s) 21.
This item is flagged for content review.
Open this question’s page →Governance and compliance
✓ Correct answer
P2 includes some established capabilities, while advanced features can require relevant Governance or Suite licensing. Actual feature support and workflow prerequisites must be checked. Licensing does not ensure trustworthy lifecycle attributes, and an Azure resource role is not an Entra Governance license. Source: AZ-305 Study Guide.pdf, PDF page(s) 21.
This item is flagged for content review.
Open this question’s page →Relational data
✓ Correct answer
SQL Database supplies the required managed SQL database. A VM adds unwanted OS/engine administration. Cosmos uses a different data/transaction model. PostgreSQL changes the required engine. Source guide: PDF page 22-23.
This item is flagged for content review.
Open this question’s page →Relational data
✓ Correct answer
Managed Instance targets high instance compatibility and these supported dependencies without guest OS management. A single SQL Database has different instance capabilities. Table is not a SQL engine. Retaining a VM without a compatibility need adds operational responsibility. Source guide: PDF page 22-23.
This item is flagged for content review.
Open this question’s page →Relational data
✓ Correct answer
SQL on a VM provides host OS and engine-version control. Managed Instance and SQL Database do not grant OS administration; Hyperscale changes storage architecture, not that control. PostgreSQL changes the engine. Source guide: PDF page 22-23.
This item is flagged for content review.
Open this question’s page →Relational data
✓ Correct answer
Flexible server preserves PostgreSQL with supported extensions and managed operations. SQL syntax does not make Azure SQL or SQL Server PostgreSQL-compatible. Cosmos JSON support does not supply the required engine. Source guide: PDF page 23.
This item is flagged for content review.
Open this question’s page →Relational data
✓ Correct answers
DTU/vCore express resource purchasing; provisioned/serverless describe compute behavior. Hyperscale is a SQL Database service tier, and Business Critical is a service tier rather than a pause policy. Source guide: PDF page 23.
This item is flagged for content review.
Open this question’s page →Relational data
✓ Correct answer
General Purpose provisioned compute fits sustained ordinary transactional load. Continuous demand defeats pause-based savings. Business Critical's low-latency architecture and Hyperscale's large-scale storage are not justified by the stated requirements; compare total cost and features before using them. Source guide: PDF page 23.
This item is flagged for content review.
Open this question’s page →Relational data
✓ Correct answer
Business Critical uses local SSD and multiple replicas with supported read scale. Basic targets a different performance class. General Purpose remote storage and extra memory do not automatically resolve measured latency. Serverless pause/compute settings do not create the Business Critical read-scale architecture. Source guide: PDF page 23.
This item is flagged for content review.
Open this question’s page →Relational data
✓ Correct answers
Hyperscale offers distributed storage and supported deployment choices; exact limits/configuration still matter. Managed Instance does not inherit Hyperscale. The guide qualifies Hyperscale auto-pause as preview, so it is not an unconditional GA assumption. Source guide: PDF page 23-24.
This item is flagged for content review.
Open this question’s page →Relational data
✓ Correct answers
Serverless and eligible pause can fit intermittent use, but storage remains billed. Open sessions can prevent pause. Autoscaling changes online capacity and does not by itself eliminate idle compute charges. Source guide: PDF page 23-24.
This item is flagged for content review.
Open this question’s page →Relational data
✓ Correct answer
Auto-pause has feature and session conditions, so inactivity alone is insufficient. Geo-replication is listed as preventing pause, not forcing synchronized pause. The vCore model does not categorically disable autoscaling. Source guide: PDF page 24.
This item is flagged for content review.
Open this question’s page →Relational data
✓ Correct answer
Auto-pause introduces resume latency and Hyperscale pause is qualified as preview. Serverless does not guarantee zero resume delay; LTR can prevent pausing. Managed Instance does not offer an interchangeable Hyperscale tier. Source guide: PDF page 24.
This item is flagged for content review.
Open this question’s page →Relational data
✓ Correct answer
The measured bottleneck is contention, so shorten/tune the blocking work. Extra cores do not release locks. Read replicas do not resolve primary write contention. Pooling resources preserves database behavior and isolation. Source guide: PDF page 24.
This item is flagged for content review.
Open this question’s page →Relational data
✓ Correct answers
An elastic pool shares capacity while keeping databases separate; limits constrain noisy tenants. It neither merges schemas nor makes aggregate capacity unlimited, so simultaneous maximum demand needs sufficient total resources. Source guide: PDF page 24-25.
This item is flagged for content review.
Open this question’s page →Relational data
✓ Correct answer
Pool and per-database constraints both apply. Individual headroom does not supply aggregate budget. Pooling does not replicate tenant writes, and limits do not guarantee contention-free simultaneous peaks. Source guide: PDF page 24.
This item is flagged for content review.
Open this question’s page →Relational data
✓ Correct answers
Read scale requires supported routing and consistency-aware clients. It offloads reads rather than increasing primary write capacity. Existing connections are not universally rerouted merely by adding a replica. Source guide: PDF page 24.
This item is flagged for content review.
Open this question’s page →Relational data
✓ Correct answer
Sharding distributes write ownership across databases but requires query/transaction design. Read-only replicas do not accept ordinary primary writes. Pooling shares resources and does not make one database unlimited. A cache is not durable write ownership. Source guide: PDF page 24.
This item is flagged for content review.
Open this question’s page →Relational data
✓ Correct answer
Online scaling can still cause reconnects/brief interruptions, so safe bounded retries are necessary. Unlimited synchronized retries can overload recovery. Repeating business effects without idempotency can create duplicates. Source guide: PDF page 24.
This item is flagged for content review.
Open this question’s page →Relational data
✓ Correct answer
TDE protects stored files/logs/backups, while Always Encrypted can protect eligible values from database-side access with separate keys. Masking changes presentation and is not encryption. Network location does not prevent authorized queries. Source guide: PDF page 24-25.
This item is flagged for content review.
Open this question’s page →Relational data
✓ Correct answers
Required key versions and accessibility are recovery dependencies. Deleting required prior keys can prevent access/restoration. Private connectivity does not grant cryptographic key permissions. Source guide: PDF page 24.
This item is flagged for content review.
Open this question’s page →Relational data
✓ Correct answer
Management-plane rights differ from database data authorization; inspect identity mapping and database roles. A Contributor assignment alone does not supply every SQL data permission, and firewall reachability does not authorize SELECT. TDE and managed identity can coexist. Source guide: PDF page 24.
This item is flagged for content review.
Open this question’s page →Relational data
✓ Correct answers
Private access still requires correct DNS/routes and principal authorization. Private networking is not an authentication bypass. A more expensive tier does not grant database permissions. Source guide: PDF page 24.
This item is flagged for content review.
Open this question’s page →Relational data
✓ Correct answer
Row-level security filters authorized rows. TDE addresses at-rest confidentiality, masking changes presentation, and LTR stores history; none of these alone enforce tenant row access. Source guide: PDF page 25.
This item is flagged for content review.
Open this question’s page →Relational data
✓ Correct answer
Auditing records activity and dynamic masking changes selected users' displayed values without becoming encryption. TDE addresses data at rest; Always Encrypted protects eligible client-encrypted values; PITR restores past database state. Those mechanisms do not by themselves supply the requested audit trail plus display policy. Source guide: PDF page 25.
This item is flagged for content review.
Open this question’s page →Relational data
✓ Correct answer
The guide limits Basic PITR retention to one-seven days. TDE does not impose the stated age limit. Geo-replication copies current changes, and ten-year LTR is selected backups rather than a ten-year PITR timeline. Source guide: PDF page 25.
This item is flagged for content review.
Open this question’s page →Relational data
✓ Correct answer
A pre-error retained point can recover good data. Geo/current read replicas can carry the delete and do not supply history. Key rotation changes cryptographic control rather than recreating records. Source guide: PDF page 25.
This item is flagged for content review.
Open this question’s page →Relational data
✓ Correct answer
General Purpose/Memory Optimized suit sustained production demand and supported HA. Burstable CPU credits can constrain continuous usage. HA standby is not normal read scale; cross-region asynchronous replicas have different promotion/data-loss semantics. Source guide: PDF page 25.
This item is flagged for content review.
Open this question’s page →Object, file, and NoSQL data
✓ Correct answer
Blob provides the required object API and media lifecycle/security features. Files adds unneeded file-share semantics; per-worker disks complicate independent shared object access. Table is a key/attribute store rather than a media-object service. Source guide: PDF page 26.
This item is flagged for content review.
Open this question’s page →Object, file, and NoSQL data
✓ Correct answer
Azure Files supports compatible shared-file protocols. Blob API access differs from SMB. Ephemeral disks are disposable, and Cosmos partition keys organize records rather than presenting a shared filesystem. Source guide: PDF page 26.
This item is flagged for content review.
Open this question’s page →Object, file, and NoSQL data
✓ Correct answer
Effective I/O is constrained by both disk and VM. A disk upgrade cannot bypass the VM cap. Archive is offline object storage, and capacity alone does not establish needed performance. Source guide: PDF page 27.
This item is flagged for content review.
Open this question’s page →Object, file, and NoSQL data
✓ Correct answers
Durable storage plus recovery protects records. Temporary and ephemeral disks are intended for disposable/recreatable data, and recreating a VM does not recreate missing business records. Source guide: PDF page 27.
This item is flagged for content review.
Open this question’s page →Object, file, and NoSQL data
✓ Correct answer
File Sync synchronizes supported Windows endpoints with Azure Files and can retain hot files locally. A direct cloud share does not supply the requested local tiering/cache layer. Blob lifecycle tiers objects rather than synchronizing the Windows file cache; backup retains recovery points rather than acting as an interactive synchronized cache. Source guide: PDF page 26-27.
This item is flagged for content review.
Open this question’s page →Object, file, and NoSQL data
✓ Correct answer
Independent historical recovery points can restore a pre-delete state. Extra synchronized copies can carry the same delete, cache capacity preserves no history by itself, and Blob tier changes do not describe Azure Files recovery. Source guide: PDF page 27.
This item is flagged for content review.
Open this question’s page →Object, file, and NoSQL data
✓ Correct answer
HNS supplies real directories and path ACLs suited to analytics. Slashes in flat object names are not equivalent. Table keys are not a directory API; worker disks alone are not a resilient shared analytics lake. Source guide: PDF page 27.
This item is flagged for content review.
Open this question’s page →Object, file, and NoSQL data
✓ Correct answer
Ordinary block-blob PITR does not support HNS, so recovery must be redesigned/verified. HNS is not corruption prevention, and namespace renaming does not preserve an independent good historical state. Source guide: PDF page 27.
This item is flagged for content review.
Open this question’s page →Object, file, and NoSQL data
✓ Correct answer
An ACL cannot remove access already sufficiently granted by data RBAC. HNS supports Entra/roles/ACLs, and management/data roles differ. Narrow the broad data-role scope if path isolation is required. Source guide: PDF page 27.
This item is flagged for content review.
Open this question’s page →Object, file, and NoSQL data
✓ Correct answers
Least-privilege data grants and required path traversal allow intended operations. A broad sufficient role cannot be narrowed by ACLs. Management-plane access does not automatically authorize file reads. Source guide: PDF page 27.
This item is flagged for content review.
Open this question’s page →Object, file, and NoSQL data
✓ Correct answer
Cool/cold remain online and can fit infrequent immediate reads. Archive requires rehydration with variable completion. LRS is redundancy, not an access tier. Source guide: PDF page 27-28.
This item is flagged for content review.
Open this question’s page →Object, file, and NoSQL data
✓ Correct answers
Delayed retrieval and long retention fit archive. A guaranteed immediate five-minute requirement does not. The guide states archive supports LRS/GRS/RA-GRS rather than ZRS/GZRS/RA-GZRS. Source guide: PDF page 27-28.
This item is flagged for content review.
Open this question’s page →Object, file, and NoSQL data
✓ Correct answer
Minimum duration is a charging rule rather than an immutable deletion ban. Cool ordinarily has thirty days, not the archive 180 days, and remains online. Source guide: PDF page 27-28.
This item is flagged for content review.
Open this question’s page →Object, file, and NoSQL data
✓ Correct answer
Total cost includes access charges as well as stored bytes. Archive adds offline retrieval and can worsen this access pattern. Online status does not eliminate retrieval/transaction pricing, and moving frequently read objects colder sooner can increase their total access cost. Source guide: PDF page 27-28.
This item is flagged for content review.
Open this question’s page →Object, file, and NoSQL data
✓ Correct answer
Lifecycle asynchronously tiers/deletes eligible objects by supported rules. It is not a guaranteed immediate callback. Manual-only changes do not supply the requested automation, and versioning retains versions without itself defining their business expiration/tiering policy. Source guide: PDF page 28.
This item is flagged for content review.
Open this question’s page →Object, file, and NoSQL data
✓ Correct answer
Protection constraints can override attempted lifecycle deletion. ZRS copies current state rather than creating undeletable history, and renaming does not universally remove retention. Legal constraints must be incorporated in policy design. Source guide: PDF page 28-30.
This item is flagged for content review.
Open this question’s page →Object, file, and NoSQL data
✓ Correct answer
RA-GZRS combines primary ZRS, asynchronous geographic copies, and supported secondary reads. LRS lacks zone/geographic separation; ZRS lacks a region copy; plain GRS lacks primary zone redundancy and pre-failover read-access behavior. Source guide: PDF page 28-29.
This item is flagged for content review.
Open this question’s page →Object, file, and NoSQL data
✓ Correct answers
Geographic replication is asynchronous and read-access variants expose supported reads. They neither provide immediate freshest writes nor fail over every application dependency. Source guide: PDF page 29.
This item is flagged for content review.
Open this question’s page →Object, file, and NoSQL data
✓ Correct answer
Archive's support excludes ZRS, and redundancy is shared at account level, so separate compatible accounts address differing needs. Containers do not independently override redundancy; Files semantics are a separate design. Source guide: PDF page 28-29.
This item is flagged for content review.
Open this question’s page →Object, file, and NoSQL data
✓ Correct answer
Geo Priority Replication has explicit scope, enablement, and exclusions and remains asynchronous. GRS does not become synchronous or writable-active-active, and the stated block-blob SLA is not a universal Files promise. Source guide: PDF page 29.
This item is flagged for content review.
Open this question’s page →Object, file, and NoSQL data
✓ Correct answer
At-rest encryption protects stored media rather than denying authorized reads. Customer-managed keys do not replace identity/data permissions. A private endpoint limits the network path but does not prohibit a permitted client from reading or exporting data. Source guide: PDF page 29.
This item is flagged for content review.
Open this question’s page →Object, file, and NoSQL data
✓ Correct answer
User delegation SAS offers supported Entra-derived signing with scoped bearer access. Account keys grant broad sensitive capability; service SAS uses an account key. Management Contributor is not an anonymous object access token. Source guide: PDF page 29.
This item is flagged for content review.
Open this question’s page →Object, file, and NoSQL data
✓ Correct answers
A SAS bearer can act within its grants, so constrain/protect it and plan revocation. Possession of the account key is not required for token use. Stored policies apply only to eligible service SAS, not all types. Source guide: PDF page 29.
This item is flagged for content review.
Open this question’s page →Object, file, and NoSQL data
✓ Correct answers
Versions/soft delete and supported PITR preserve usable historical states. Replication can propagate an overwrite; encryption-key rotation does not reconstruct old values. Source guide: PDF page 29.
This item is flagged for content review.
Open this question’s page →Object, file, and NoSQL data
✓ Correct answer
Protection mechanisms have distinct scopes. Container deletion protection is not an unlimited object/version or storage-account recovery system. HNS overwrite and replica history assumptions are unsupported. Source guide: PDF page 29.
This item is flagged for content review.
Open this question’s page →Object, file, and NoSQL data
✓ Correct answer
Immutability enforces eligible WORM retention. Soft delete offers an undo window rather than prohibiting every modification. Archive is an access tier, while versioning retains supported previous versions without itself creating the requested immutable retention boundary. Source guide: PDF page 29-30.
This item is flagged for content review.
Open this question’s page →Object, file, and NoSQL data
✓ Correct answer
Cosmos NoSQL fits the document/operational/regional pattern, with session tokens for session guarantees. Files and archive do not satisfy those query semantics. Table does not inherit the entire Cosmos feature matrix. Source guide: PDF page 30-31.
This item is flagged for content review.
Open this question’s page →Object, file, and NoSQL data
✓ Correct answer
A hot key can remain limited despite global spare throughput. A redesigned key distributes actual demand, usually requiring migration. Unused keys do not move hot traffic, and Blob archive does not change Cosmos partitioning. Source guide: PDF page 30-31.
This item is flagged for content review.
Open this question’s page →Object, file, and NoSQL data
✓ Correct answer
Hierarchical keys can distribute a tenant prefix across full key values under documented limits. Constant/hot keys retain limits; random keys can force expensive scans. Physical scaling does not remove a conventional logical partition's limits. Source guide: PDF page 30.
This item is flagged for content review.
Open this question’s page →Object, file, and NoSQL data
✓ Correct answers
Ordinary NoSQL transactions are logical-partition scoped, so key design affects invariants. Multi-write regional topology does not extend arbitrary cross-partition atomicity. Source guide: PDF page 30-31.
This item is flagged for content review.
Open this question’s page →Object, file, and NoSQL data
✓ Correct answer
150 × 4 = 600 and 50 × 12 = 600, totaling 1,200 RU/s before headroom. 200 counts requests without operation cost; 600 includes only one workload; 800 incorrectly prices all 200 operations as 4-RU reads. Source guide: PDF page 30.
This item is flagged for content review.
Open this question’s page →Object, file, and NoSQL data
✓ Correct answer
The stated serverless single-region restriction excludes that choice for two regions. Manual capacity does not repair skew, and vCore MongoDB is a different offering whose model must be checked. Source guide: PDF page 30-31.
This item is flagged for content review.
Open this question’s page →Object, file, and NoSQL data
✓ Correct answers
Session consistency provides documented session guarantees with correct tokens. Eventual has no such unconditional guarantee, while multi-write strong is unsupported and stronger than the stated unrelated-reader need. Source guide: PDF page 31.
This item is flagged for content review.
Open this question’s page →Object, file, and NoSQL data
✓ Correct answer
Bounded staleness states explicit version/time bounds. Eventual supplies convergence without a fixed freshness bound; consistent prefix addresses ordering; session addresses client-session guarantees rather than the required universal freshness bound. Source guide: PDF page 31.
This item is flagged for content review.
Open this question’s page →Integration and analytics
✓ Correct answer
Ingestion/storage alone does not create validated analytical models. More capacity or another raw copy does not define business transformations or quality checks. Purview cataloging tracks/discovers data rather than executing the missing pipeline. Source guide: PDF page 32-34.
This item is flagged for content review.
Open this question’s page →Integration and analytics
✓ Correct answer
Separating OLAP capacity and data layout isolates large scans from OLTP while freshness drives integration. More scans worsen contention. Larger primary capacity may help temporarily but does not provide independent analytical workload isolation; cataloging does not change where expensive queries run. Source guide: PDF page 32.
This item is flagged for content review.
Open this question’s page →Integration and analytics
✓ Correct answer
ETL transforms before final destination load and can reduce sensitive exposure. An unrestricted raw ELT landing conflicts with the stated policy. Copying and classification do not themselves remove fields or enforce the intended transformation. Source guide: PDF page 32.
This item is flagged for content review.
Open this question’s page →Integration and analytics
✓ Correct answers
ELT/raw retention enables replay while security/retention governs cost/exposure. Immediate deletion removes reprocessing input. Raw and quarantine records can contain sensitive data and need access control. Source guide: PDF page 32-33.
This item is flagged for content review.
Open this question’s page →Integration and analytics
✓ Correct answer
The fault is incomplete change capture. Robust boundaries/deletion handling or supported CDC addresses it; reconciliation proves effects. Faster destination compute and activity success do not correct missing changes, and losing tracked progress worsens recovery. Source guide: PDF page 32.
This item is flagged for content review.
Open this question’s page →Integration and analytics
✓ Correct answers
Tracked progress and idempotent writes support recovery without repeated business effects. Success flags do not reconcile results, and retries can duplicate delivery/effects unless the end-to-end design prevents them. Source guide: PDF page 32-34.
This item is flagged for content review.
Open this question’s page →Integration and analytics
✓ Correct answer
Reconciliation tests substantive correctness beyond transport completion. Success flags, faster copy/network metrics, and retention do not prove that the correct records and financial totals were produced. Source guide: PDF page 32.
This item is flagged for content review.
Open this question’s page →Integration and analytics
✓ Correct answer
The layers distinguish source retention, cleansing, and serving. Raw is not automatically curated, quarantine needs protection, and refined output does not eliminate replay/security requirements. Source guide: PDF page 33.
This item is flagged for content review.
Open this question’s page →Integration and analytics
✓ Correct answers
Self-hosted runtime reaches supported private sources; connection credentials and network reachability both matter. Authentication cannot create routes, and Azure-SSIS is for supported existing SSIS package execution rather than every SQL source. Source guide: PDF page 33.
This item is flagged for content review.
Open this question’s page →Integration and analytics
✓ Correct answer
Azure-SSIS IR is the supported SSIS execution option. Managed cloud copy runtime and self-hosted connectivity are different runtime purposes. SQL resource pooling is not package execution. Source guide: PDF page 33.
This item is flagged for content review.
Open this question’s page →Integration and analytics
✓ Correct answer
Supported multiple nodes improve runtime availability/capacity. Connection definitions and destination capacity do not replace a failed execution machine. Manual-only restart of the same node leaves the single-node maintenance failure boundary. Source guide: PDF page 33.
This item is flagged for content review.
Open this question’s page →Integration and analytics
✓ Correct answer
Pipelines/runtimes integrate data; datasets identify it and linked services describe connections. None of those definitions automatically creates the historical warehouse. Source guide: PDF page 33.
This item is flagged for content review.
Open this question’s page →Integration and analytics
✓ Correct answer
Synapse dedicated SQL pools supply allocated distributed warehouse processing within the broader SQL/Spark/pipeline platform. Serverless has different capabilities/cost. SQL Database alone does not provide that integrated environment, and Copy Activity moves data rather than supplies the warehouse serving engine. Source guide: PDF page 33-34.
This item is flagged for content review.
Open this question’s page →Integration and analytics
✓ Correct answers
Serverless SQL and efficient file layouts can fit occasional eligible queries. Dedicated capacity bills differently; unpartitioned row-oriented scans may process more data and are not guaranteed cheapest. Source guide: PDF page 34.
This item is flagged for content review.
Open this question’s page →Integration and analytics
✓ Correct answer
Distributed warehouse performance depends on table placement, movement, indexing, and queries. Catalog counts do not reveal the bottleneck. Capacity can help but may preserve inefficient data movement, and changing ingestion schedule does not automatically fix distributed join execution. Source guide: PDF page 34.
This item is flagged for content review.
Open this question’s page →Integration and analytics
✓ Correct answer
Databricks supplies the requested Spark/lakehouse engineering environment. A dedicated SQL pool alone is a warehouse SQL engine; ADX focuses on KQL event exploration rather than supplying the stated Spark ecosystem. Copy Activity moves data and does not replace the required transformation/engineering engine. Source guide: PDF page 33.
This item is flagged for content review.
Open this question’s page →Integration and analytics
✓ Correct answer
Fabric's integrated model fits but capacity/governance and compatibility still matter. Integration does not eliminate migration, data-quality, or platform feature differences. Source guide: PDF page 33-34.
This item is flagged for content review.
Open this question’s page →Integration and analytics
✓ Correct answer
ADX targets interactive telemetry/log/time-series analytics using KQL. SQL instance compatibility and warehouse capacity alone do not match the stated KQL exploration requirement. Stream Analytics processes supported streams, but is not itself the durable interactive KQL event-serving store. Source guide: PDF page 34.
This item is flagged for content review.
Open this question’s page →Integration and analytics
✓ Correct answer
Different freshness/correctness requirements justify batch finance and streaming telemetry, each with validation/serving. Nightly processing misses seconds freshness; broker arrival alone does not validate finance; a catalog is not ingestion. Source guide: PDF page 34-35.
This item is flagged for content review.
Open this question’s page →Integration and analytics
✓ Correct answers
Tumbling windows form non-overlapping intervals; late events and replay need explicit correctness policies. Sliding windows are moving intervals. Strong component delivery does not by itself prevent all downstream duplicate business effects. Source guide: PDF page 34.
This item is flagged for content review.
Open this question’s page →Integration and analytics
✓ Correct answer
Purview supports governance/discovery/classification/lineage, while underlying authorization remains separate. Membership is not universal data permission. Execution logs and file ACLs are useful operational/security controls but do not alone provide the requested governed classification and source-to-report lineage. Source guide: PDF page 34.
This item is flagged for content review.
Open this question’s page →Integration and analytics
✓ Correct answer
Network execution/connectivity must fit the source. Credentials establish identity rather than routes; warehouse capacity and checkpoints do not solve source reachability. Source guide: PDF page 33.
This item is flagged for content review.
Open this question’s page →Backup and disaster recovery
✓ Correct answer
Data gap is incident minus usable point: eight minutes. Recovery duration is restored business service minus incident: forty-one minutes. Reversing the metrics confuses RPO/RTO; the clock minute itself is not an interval, and a point's existence does not imply zero loss. Source guide: PDF page 36.
This item is flagged for content review.
Open this question’s page →Backup and disaster recovery
✓ Correct answer
Worst-case usable-point age can approach an hour, exceeding the five-minute data-loss objective. Restore start/VM startup relates to recovery time, not data gap, and an hourly point cannot contain all later writes. Source guide: PDF page 36.
This item is flagged for content review.
Open this question’s page →Backup and disaster recovery
✓ Correct answer
For the stated sequential process, 12+18+15=45 minutes to business recovery. RTO includes dependencies and validation. These elapsed recovery steps do not establish a data-loss gap, and subtracting required work is invalid. Source guide: PDF page 36.
This item is flagged for content review.
Open this question’s page →Backup and disaster recovery
✓ Correct answers
Protected retained points and independent critical-operation authorization reduce a single identity's destructive reach. Shared unrestricted guard/vault ownership collapses separation, and more administrators using the same powerful credential do not create an independent permission boundary. Source guide: PDF page 36-37.
This item is flagged for content review.
Open this question’s page →Backup and disaster recovery
✓ Correct answer
Vault/workload support and configured regional restore capabilities determine accessibility. GRS alone does not supply universal immediate arbitrary-region restore. Primary job success or choosing a resource-group location does not prove support for the desired secondary-region operation. Source guide: PDF page 37.
This item is flagged for content review.
Open this question’s page →Backup and disaster recovery
✓ Correct answer
Soft delete is a time-limited undo mechanism and needs monitoring. It is not permanent immutability; Resource Guard authorizes critical operations rather than recreating expired points, and redundancy does not change this policy window. Source guide: PDF page 37.
This item is flagged for content review.
Open this question’s page →Backup and disaster recovery
✓ Correct answer
Azure Backup VM protection targets retained supported VM/disk/file recovery and requires scope/consistency validation. Replication alone is not historical recovery. MARS is not a universal VM backup replacement, and vault support must be checked. Source guide: PDF page 36-38.
This item is flagged for content review.
Open this question’s page →Backup and disaster recovery
✓ Correct answer
Application consistency coordinates eligible state. Crash consistency may need application log replay and is not equivalent. Excluding business disks omits data; placement is fault isolation rather than validation of recovery state. Source guide: PDF page 37-38.
This item is flagged for content review.
Open this question’s page →Backup and disaster recovery
✓ Correct answers
IaC rebuilds configuration/compute, while business data and dependencies need independent protection. Versioned configuration does not recreate missing records, and temporary storage is unsuitable for the sole durable order copy. Source guide: PDF page 38.
This item is flagged for content review.
Open this question’s page →Backup and disaster recovery
✓ Correct answer
MARS has eligible Windows file/folder scope; MABS/DPM cover broader supported workloads with their own operation requirements. SQL PITR protects SQL PaaS data, and synchronization alone does not preserve all application history. Source guide: PDF page 37-38.
This item is flagged for content review.
Open this question’s page →Backup and disaster recovery
✓ Correct answers
Application resources/persistent volumes plus external state are needed. Worker OS images do not automatically contain the full application definition/history, and probes determine health rather than retain data. Source guide: PDF page 38.
This item is flagged for content review.
Open this question’s page →Backup and disaster recovery
✓ Correct answer
Physical-source failback has the documented VMware target restriction. Source platforms have distinct flows, so a generic VM-source procedure cannot be assumed applicable. Successful boot in Azure does not prove support for returning to original physical hardware. Source guide: PDF page 38.
This item is flagged for content review.
Open this question’s page →Backup and disaster recovery
✓ Correct answer
PITR uses retained native SQL backups to recover an earlier/new database. Current replicas can contain the delete. SQL PaaS is not a guest VM backup target, and TDE does not generate deleted rows. Source guide: PDF page 38-39.
This item is flagged for content review.
Open this question’s page →Backup and disaster recovery
✓ Correct answer
LTR supports selected backups up to ten years, separate from short-term PITR. Current replicas/failover groups maintain current state rather than years of independent historical backups, and ordinary PITR does not span seven years. Source guide: PDF page 38.
This item is flagged for content review.
Open this question’s page →Backup and disaster recovery
✓ Correct answers
Baseline/differential/log chains enable workload-aware selected-time restore; frequent successful logs support the intended gap. An OS snapshot excludes the precise chain, and routing reports to replicas provides no historical timeline. Source guide: PDF page 38-39.
This item is flagged for content review.
Open this question’s page →Backup and disaster recovery
✓ Correct answer
A valid chain determines reachable points. Logs require the proper database chain rather than an empty baseline; a differential relates to its full baseline. VM snapshots are different from proving SQL log continuity. Source guide: PDF page 39.
This item is flagged for content review.
Open this question’s page →Backup and disaster recovery
✓ Correct answers
Cosmos continuous backup has specific retention, API, and restore scope/timestamp details. Regional current-state copies are not a permanent history, and SQL product limits cannot be transferred without verification. Source guide: PDF page 39.
This item is flagged for content review.
Open this question’s page →Backup and disaster recovery
✓ Correct answer
A ready secondary can reduce activation work compared with geo-restore, while asynchronous forced failover can lose recent writes and backups preserve history. TDE and MARS do not supply SQL PaaS regional replication. Source guide: PDF page 38-39.
This item is flagged for content review.
Open this question’s page →Backup and disaster recovery
✓ Correct answers
Supported geo backups and cross-region replicas provide distinct regional RPO/RTO options. Local HA is a different failure boundary, and SQL product tiers do not supply PostgreSQL compatibility. Source guide: PDF page 39.
This item is flagged for content review.
Open this question’s page →Backup and disaster recovery
✓ Correct answer
Vaulted backup retains eligible offsite protected data. Operational PITR and source-only versions reside in the source account; redundancy is not independent historical protection against every destructive account event. Source guide: PDF page 39.
This item is flagged for content review.
Open this question’s page →Backup and disaster recovery
✓ Correct answer
Operational protection relies on source-account PITR/versioning/soft-delete/change-feed, so it is not an isolated vaulted copy. Account deletion and HNS compatibility need distinct protection checks. This item concerns an existing policy, avoiding assumptions about current new-policy creation options. Source guide: PDF page 37-39.
This item is flagged for content review.
Open this question’s page →Backup and disaster recovery
✓ Correct answers
Backup compatibility varies and ordinary block-blob PITR excludes HNS. Operational/vaulted methods are not identical, and ACLs control access rather than retain historical data. Source guide: PDF page 39.
This item is flagged for content review.
Open this question’s page →Backup and disaster recovery
✓ Correct answer
History and fault-boundary resilience solve distinct incidents. ZRS and synchronization can copy bad current state; archive is offline object storage rather than equivalent SMB recovery. Source guide: PDF page 39.
This item is flagged for content review.
Open this question’s page →Backup and disaster recovery
✓ Correct answer
The proposal combines unsupported SSD geo-redundancy and Files readable-secondary assumptions. RA naming does not create secondary Files access, and an endpoint does not alter the share redundancy support matrix. Source guide: PDF page 39.
This item is flagged for content review.
Open this question’s page →Backup and disaster recovery
✓ Correct answers
Geographic replication can lag, and clients/application dependencies need supported recovery/reconnection. It is not synchronous zero-loss replication; Blob read-access semantics do not remove Files-specific failover behavior. Source guide: PDF page 39-42.
This item is flagged for content review.
Open this question’s page →Backup and disaster recovery
✓ Correct answer
Prepared dependencies and ordered startup/validation make the service usable; isolated drills test this without interfering with production. Boot alone is insufficient, duplicate production writers are unsafe, and disk copies do not reconstruct all external state. Source guide: PDF page 38-39.
This item is flagged for content review.
Open this question’s page →High availability
✓ Correct answer
Deliberate zone spread and end-to-end dependencies address a zone failure. Sets distribute local fault/update domains rather than supplying a regional/zone-spanning application guarantee. Disk copies do not supply a replacement worker, and pairing deploys no app topology. Source guide: PDF page 40.
This item is flagged for content review.
Open this question’s page →High availability
✓ Correct answer
Two surviving zones offer 800 requests/s, below the required 1,000 by 200. Zone count alone does not prove capacity. Backup retention and probes do not supply the missing processing resources. Source guide: PDF page 40.
This item is flagged for content review.
Open this question’s page →High availability
✓ Correct answers
Resilient state and healthy routing enable replacement workers to serve correctly. A scale set does not reconstruct arbitrary memory; extra stateless capacity alone does not retain sessions. Source guide: PDF page 40.
This item is flagged for content review.
Open this question’s page →High availability
✓ Correct answer
Zone resilience is configuration-specific and requires sufficient surviving capacity. Region capability does not automatically enable it; more cores on one zonal instance do not create zone isolation. Backup restores support recovery but are not an already serving redundant worker. Source guide: PDF page 40.
This item is flagged for content review.
Open this question’s page →High availability
✓ Correct answers
Replica placement, probes, storage, and capacity protect the workload. Managed control-plane availability does not make one pod redundant, and PDBs primarily govern eligible voluntary disruption rather than preventing infrastructure loss. Source guide: PDF page 40-41.
This item is flagged for content review.
Open this question’s page →High availability
✓ Correct answer
Bounded backoff reduces overload while idempotency prevents repeated business effects. Unlimited synchronized retry can congest recovery; new-transaction retries duplicate orders, and hiding failures indefinitely prevents bounded service behavior. Source guide: PDF page 41.
This item is flagged for content review.
Open this question’s page →High availability
✓ Correct answer
0.999×0.9995=0.9985005, about 99.85%. Required serial dependencies reduce the independent modeled availability. Addition and choosing the higher value are invalid; mathematical estimates alone do not create contractual guarantees. Source guide: PDF page 42.
This item is flagged for content review.
Open this question’s page →High availability
✓ Correct answers
Managed local HA and supported enabled zone resilience are distinct. A backup restore requires recovery work, and local HA does not imply every tier/configuration is zone-redundant. Source guide: PDF page 41.
This item is flagged for content review.
Open this question’s page →High availability
✓ Correct answer
The guide specifically qualifies Next-gen General Purpose zone redundancy as preview with underlying support conditions. Product tiers/generations differ, and reporting access does not establish zone/regional protection for all dependencies. Source guide: PDF page 41.
This item is flagged for content review.
Open this question’s page →High availability
✓ Correct answer
VM placement reduces certain infrastructure risks but does not create SQL HA topology. Availability groups/clusters and associated coordination/connectivity must be configured; scaling/routing alone does not replicate the database. Source guide: PDF page 41.
This item is flagged for content review.
Open this question’s page →High availability
✓ Correct answers
Synchronous covered-local and asynchronous regional mechanisms have distinct guarantees. Geographic async writes can lag, and VM placement does not itself implement transaction replication. Source guide: PDF page 41.
This item is flagged for content review.
Open this question’s page →High availability
✓ Correct answer
Cross-zone supported HA separates the relevant infrastructure boundary. More same-zone copies do not isolate the zone; standby reporting is not its role; backup restore is different from ready automatic HA. Source guide: PDF page 41.
This item is flagged for content review.
Open this question’s page →High availability
✓ Correct answer
The HA standby is not the ordinary reporting replica, while asynchronous replicas have their own consistency/promotion behavior. Neither changes write capacity as described, and local HA does not automatically span a region outage. Source guide: PDF page 41.
This item is flagged for content review.
Open this question’s page →High availability
✓ Correct answer
Synchronizing a planned transition differs from forcing an available async secondary when source changes may be missing. Neither operation inherently recovers pre-delete history. Connections can be interrupted even when committed writes survive. Source guide: PDF page 25,41.
This item is flagged for content review.
Open this question’s page →High availability
✓ Correct answer
GZRS combines primary zone redundancy and asynchronous geographic replication. Application failover remains separate. LRS lacks geographic/zone spread, ZRS lacks a regional copy, and legal retention does not deploy replicas. Source guide: PDF page 41.
This item is flagged for content review.
Open this question’s page →High availability
✓ Correct answers
RA secondary access is supported read-only with async lag, and end-to-end recovery includes every dependency. It does not create independent multiwriter behavior or historical backup retention. Source guide: PDF page 41.
This item is flagged for content review.
Open this question’s page →High availability
✓ Correct answer
Supported ZRS covers the zone boundary while clients/performance support real service continuity. Retries cannot add missing copies, Files secondary access differs from Blob, and key rotation does not guarantee session continuity. Source guide: PDF page 41-42.
This item is flagged for content review.
Open this question’s page →High availability
✓ Correct answer
The guide separates supported HDD geo-failover from SSD lack of GRS/GZRS. Read-access naming and File Sync do not override share support restrictions. Source guide: PDF page 41-42.
This item is flagged for content review.
Open this question’s page →High availability
✓ Correct answers
Multi-write requires supported consistency/conflict handling and coordinated regional/SDK resilience. Strong is incompatible with multiple write regions and serverless is single-region under the documented model. Source guide: PDF page 42.
This item is flagged for content review.
Open this question’s page →High availability
✓ Correct answer
LWW selects a winning update; it is not an accounting merge. Business invariants require appropriate conflict/serialization/idempotency design. Read consistency and replica count do not supply missing merge semantics or arbitrary global transactions. Source guide: PDF page 31,42.
This item is flagged for content review.
Open this question’s page →High availability
✓ Correct answer
Consistent prefix addresses ordering without guaranteeing newest data. Strong supplies stricter latest-value behavior than requested. Eventual does not supply a fixed freshness bound, and bounded staleness is a bound rather than a license to reorder arbitrarily. Source guide: PDF page 31,42.
This item is flagged for content review.
Open this question’s page →High availability
✓ Correct answers
Region pairing is service-specific and not universal application DR. Topology, capacity, destinations, and routing remain architectural choices. It neither deploys every dependency nor applies identically to all regions. Source guide: PDF page 42.
This item is flagged for content review.
Open this question’s page →Compute design
✓ Correct answer
Virtual Machines provide guest OS administrator control and compatibility for the unchanged service. Flex Consumption abstracts the guest OS, Container Apps expects supported container packaging, and App Service supplies managed web hosting rather than an unrestricted Windows server. Source guide: PDF page(s) 43.
This item is flagged for content review.
Open this question’s page →Compute design
✓ Correct answer
Component-level design can combine a VM, managed web hosting, and Batch or suitable event compute. Functions cannot automatically satisfy arbitrary guest service requirements; one large VM concentrates failure and does not inherently improve availability; AKS does not remove workload or cluster operations and is not justified solely by packaging. Source guide: PDF page(s) 43, 48.
This item is flagged for content review.
Open this question’s page →Compute design
✓ Correct answer
The VM's aggregate IOPS cap can limit the disk path, so VM and disk sizing must be evaluated together. More disk IOPS cannot remove that VM cap, temporary storage is not durable business storage, and MB/s alone does not characterize small random I/O demand. Source guide: PDF page(s) 44.
This item is flagged for content review.
Open this question’s page →Compute design
✓ Correct answer
An ephemeral OS disk fits replaceable stateless instances whose state is external. Ultra Disk and Premium SSD v2 are data-disk options, not OS disks; storing the only output on temporary local storage contradicts durability. Source guide: PDF page(s) 44-45.
This item is flagged for content review.
Open this question’s page →Compute design
✓ Correct answer
Premium SSD v2 permits independent capacity and performance configuration for supported data disks. Standard HDD does not meet that tunable-performance requirement, while ephemeral OS and temporary disks are local replaceable storage rather than this managed data-disk design. Source guide: PDF page(s) 45.
This item is flagged for content review.
Open this question’s page →Compute design
✓ Correct answers
Disk performance must fit both device and VM limits, and advanced disk availability has VM and location constraints. Premium SSD v2 cannot be assumed to support OS use; IOPS measures operation rate rather than transfer rate; temporary local storage is unsuitable for recovery-critical data. Source guide: PDF page(s) 44-45.
This item is flagged for content review.
Open this question’s page →Compute design
✓ Correct answer
A versioned image pipeline and Compute Gallery preserve approved configuration. Undocumented edits remain unrepeatable, a mutable image does not capture production's manual drift, and unversioned local instructions can create inconsistent replacements. Source guide: PDF page(s) 44.
This item is flagged for content review.
Open this question’s page →Compute design
✓ Correct answer
Queue depth measures unmet demand when workers are I/O-bound. CPU can miss this bottleneck, instance count describes allocation rather than backlog, and completed-task count alone can hide accumulating work. Scaling must still protect downstream capacity. Source guide: PDF page(s) 45.
This item is flagged for content review.
Open this question’s page →Compute design
✓ Correct answers
Aggregation, cooldowns, and sensible bounds reduce reaction to transient samples and control capacity. Unbounded scaling risks cost and dependency overload, immediate scale-in encourages oscillation, and memory-only progress threatens durability rather than fixing control behavior. Source guide: PDF page(s) 45.
This item is flagged for content review.
Open this question’s page →Compute design
✓ Correct answer
Flexible manages standard VMs and currently supports autoscale and standard VM integrations. Uniform uses scale-set child APIs and has different integration support; availability sets are placement constructs without metric autoscale; claiming Flexible cannot autoscale is outdated. Source guide: PDF page(s) 45.
This item is flagged for content review.
Open this question’s page →Compute design
✓ Correct answer
Uniform coordinates common-profile machines through scale-set APIs. Availability sets supply placement rather than fleet management and automatic app balancing, one large VM is not the fleet, and uncoordinated VMs lack the common profile. Source guide: PDF page(s) 45.
This item is flagged for content review.
Open this question’s page →Compute design
✓ Correct answer
Zone placement must be combined with enough healthy surviving compute and dependency capacity. Three zones alone do not create headroom, temporary disks are not a replicated durable data design, and a regional scale set does not add cross-region replication. Source guide: PDF page(s) 45.
This item is flagged for content review.
Open this question’s page →Compute design
✓ Correct answers
Quota supplies allocation permission and a successful capacity reservation secures supported physical capacity. Reserved VM Instances primarily discount billing, Spot can be evicted, and quota increases do not manufacture or reserve hardware. Source guide: PDF page(s) 45.
This item is flagged for content review.
Open this question’s page →Compute design
✓ Correct answer
A Reserved VM Instance is a price commitment rather than a hardware guarantee. It neither guarantees arbitrary SKUs nor changes all quotas, and it does not change Spot's eviction model. A capacity reservation addresses the separate capacity requirement. Source guide: PDF page(s) 45.
This item is flagged for content review.
Open this question’s page →Compute design
✓ Correct answer
Separate plans provide independent worker and scaling boundaries. Slots share plan compute, stopping an app generally does not stop plan charges, and per-app limits do not convert shared capacity into dedicated independent plans. Source guide: PDF page(s) 46.
This item is flagged for content review.
Open this question’s page →Compute design
✓ Correct answer
Slot settings retain environment-specific values with their intended slot. Embedding the value in swapped content can move it to production, not every setting is automatically sticky, and deployment slots are live endpoints on shared regional plan capacity rather than cross-region recovery. Source guide: PDF page(s) 46.
This item is flagged for content review.
Open this question’s page →Compute design
✓ Correct answer
The worker limit can prevent simultaneous hot application replicas even when plan workers are distributed. Plan zones do not guarantee every app's placement, the universal exactly-three rule is outdated, and compute placement does not geo-replicate databases. Source guide: PDF page(s) 46.
This item is flagged for content review.
Open this question’s page →Compute design
✓ Correct answers
Outbound VNet integration and inbound private endpoints or restrictions solve distinct network directions. Integration alone does not privatize the web endpoint, NAT supplies outbound translation rather than API ingress policy, and network reachability does not replace database authorization. Source guide: PDF page(s) 46.
This item is flagged for content review.
Open this question’s page →Compute design
✓ Correct answer
Container Apps supplies revisions and event scaling while abstracting cluster operations. AKS may work but adds control and responsibility not required here; Container Registry stores artifacts; an availability set provides VM placement rather than managed container release and scaling. Source guide: PDF page(s) 46-47.
This item is flagged for content review.
Open this question’s page →Compute design
✓ Correct answer
AKS exposes Kubernetes control and ecosystem integration. Container Apps abstracts the underlying cluster, Container Instances offers container groups without a full Kubernetes platform, and App Service slots do not implement custom cluster controllers. Source guide: PDF page(s) 46-47.
This item is flagged for content review.
Open this question’s page →Compute design
✓ Correct answer
Container Instances fits a simple short-lived group with shared lifecycle and networking. Registry does not execute images, AKS adds cluster operations unjustified by this simple requirement, and web slots are release endpoints rather than isolated group task scheduling. Source guide: PDF page(s) 47.
This item is flagged for content review.
Open this question’s page →Compute design
✓ Correct answers
Cluster autoscaling adds supported node capacity and sensible resource requests enable scheduling. More replicas alone cannot create nodes, NSG rules do not solve resource scheduling, and a managed control plane does not supply unlimited worker capacity. Source guide: PDF page(s) 46.
This item is flagged for content review.
Open this question’s page →Compute design
✓ Correct answers
Replica diversity and controlled disruption with readiness and capacity improve maintenance tolerance. Local-only state can lose data, a managed control plane cannot protect a single pod from all failures, and mutable unreviewed images undermine release control. Source guide: PDF page(s) 46.
This item is flagged for content review.
Open this question’s page →Compute design
✓ Correct answer
A corrected, scanned, controlled image gives reproducible replacement of vulnerable code. In-place patches disappear on recreation and leave the source vulnerable, registry storage is not a security guarantee, and anonymous access weakens image protection rather than fixing dependencies. Source guide: PDF page(s) 46.
This item is flagged for content review.
Open this question’s page →Compute design
✓ Correct answer
Minimum replicas maintain running capacity. Traffic weighting without a warm instance does not guarantee startup latency, termination grace concerns stopping instances, and a longer HTTP timeout tolerates delay rather than meeting the latency target. Source guide: PDF page(s) 46-47.
This item is flagged for content review.
Open this question’s page →Compute design
✓ Correct answer
Flex provides event-driven scale and outbound VNet integration for supported code workloads. Legacy Consumption has different limits, Dedicated allocates plan capacity, and Premium maintains a minimum provisioned cost. Plans must be selected by actual networking, latency, and billing needs. Source guide: PDF page(s) 47.
This item is flagged for content review.
Open this question’s page →Compute design
✓ Correct answer
Premium supports prewarmed event-driven capacity and appropriate private networking and custom Linux containers. The Flex option incorrectly assumes arbitrary custom containers, legacy Consumption does not eliminate networking or HTTP duration limits, and a Free plan does not provide Premium capabilities. Source guide: PDF page(s) 47.
This item is flagged for content review.
Open this question’s page →Compute design
✓ Correct answer
Always On keeps the dedicated host active when continuous triggers require it. CPU autoscale does not itself prevent host idle, execution duration controls invocations rather than host keep-alive, and slots promote releases rather than ensure continuous host operation. Source guide: PDF page(s) 47.
This item is flagged for content review.
Open this question’s page →Compute design
✓ Correct answers
Accepted/status semantics and queued or durable processing separate the request lifetime from long work and persist progress. A longer function execution setting does not remove the documented HTTP response limit, host memory is not durable, and legacy Consumption has a maximum execution duration rather than unlimited uninterrupted runtime. Source guide: PDF page(s) 47-48.
This item is flagged for content review.
Open this question’s page →Compute design
✓ Correct answer
Activities are the appropriate place for external and nondeterministic work while deterministic orchestration replays recorded history. Process memory loses durability, disabling retries does not erase replay requirements, and changing to another random API preserves the same nondeterminism. Source guide: PDF page(s) 47.
This item is flagged for content review.
Open this question’s page →Compute design
✓ Correct answer
Durable orchestration can persist state and wait for external events without one continuous ordinary execution. Synchronous requests and sleeping legacy invocations exceed their lifetime constraints, while an in-process cache is not a durable approval record. Source guide: PDF page(s) 47.
This item is flagged for content review.
Open this question’s page →Compute design
✓ Correct answer
Payment-side idempotency links retries to one intended business effect. Deterministic orchestration is necessary for replay but does not make external side effects exactly once; longer timeouts and larger plans do not close the response-loss duplication window. Source guide: PDF page(s) 47.
This item is flagged for content review.
Open this question’s page →Compute design
✓ Correct answers
Execution configuration does not remove host-lifecycle behavior or the HTTP path's response limit. Unbounded is not an uninterrupted-process guarantee, HTTP lifetime is distinct from workflow lifetime, and legacy Consumption retains different timeout limits. Source guide: PDF page(s) 47-48.
This item is flagged for content review.
Open this question’s page →Compute design
✓ Correct answer
Batch provides pools and parallel job/task scheduling. One legacy Consumption invocation has a limited lifetime and is not a fleet scheduler, web hosting alone lacks Batch scheduling, and one uncoordinated group does not schedule the parallel task fleet. Source guide: PDF page(s) 48.
This item is flagged for content review.
Open this question’s page →Compute design
✓ Correct answer
Start tasks and controlled images/packages prepare nodes. Job release runs after work, dependencies order tasks without supplying missing software, and autoscale changes capacity rather than installation. Source guide: PDF page(s) 48.
This item is flagged for content review.
Open this question’s page →Compute design
✓ Correct answers
A mixed pool combines reliable dedicated capacity with cheaper interruption-tolerant throughput, and external checkpoints support recovery. Spot can still be evicted, temporary-only checkpoints can disappear, and account or VM quotas can constrain pool growth. Source guide: PDF page(s) 48.
This item is flagged for content review.
Open this question’s page →Compute design
✓ Correct answer
CycleCloud is intended for customized HPC infrastructure with a customer-operated scheduler. Batch has its own pool/job/task model and does not automatically preserve every external scheduler; a registry and web slots do not allocate the required HPC scheduler topology. Source guide: PDF page(s) 48.
This item is flagged for content review.
Open this question’s page →Compute design
✓ Correct answer
Multi-instance tasks coordinate supported tightly coupled MPI execution. Uncoordinated tasks, capacity autoscale alone, and completion dependencies between separate single-node commands do not supply simultaneous distributed execution and communication. Source guide: PDF page(s) 48.
This item is flagged for content review.
Open this question’s page →Application architecture
✓ Correct answer
A queue distributes one logical work stream among competing receivers and retains pending work. Separate subscriptions or independent Event Hubs groups give each worker a copy rather than dividing fulfillment, while synchronous calls couple acceptance to every worker's availability. Processing still needs idempotency for redelivery. Source guide: PDF page(s) 49-50.
This item is flagged for content review.
Open this question’s page →Application architecture
✓ Correct answer
Topic subscriptions maintain independent copies and processing progress for each department. Competing consumers on one queue divide messages, so each department would miss orders; sessions manage related-message order and ownership rather than creating independent department copies. Source guide: PDF page(s) 50.
This item is flagged for content review.
Open this question’s page →Application architecture
✓ Correct answer
Peek Lock preserves recoverability until the receiver completes the message. Receive and Delete removes at receipt, completing early can lose work on a later failure, and broker reception does not provide automatic rollback of external SQL writes. Source guide: PDF page(s) 50.
This item is flagged for content review.
Open this question’s page →Application architecture
✓ Correct answer
Database-enforced business idempotency handles redelivery after a successful write and lost completion. Broker duplicate detection primarily suppresses duplicate sends within its window, a new ID does not recognize the existing effect, and arbitrary SQL plus message completion is not automatically one distributed transaction. Source guide: PDF page(s) 50.
This item is flagged for content review.
Open this question’s page →Application architecture
✓ Correct answers
Account-scoped sessions provide the required local ordering, and idempotency protects repeated business processing. One global session serializes unrelated accounts, duplicate detection does not guarantee external execution exactly once, and Receive and Delete loses the message before processing recovery is assured. Source guide: PDF page(s) 50-51.
This item is flagged for content review.
Open this question’s page →Application architecture
✓ Correct answer
Dead-lettering retains failure evidence for a managed business recovery process. Endless retries waste capacity, immediate untracked deletion loses work, and the dead-letter queue does not repair invalid business data automatically. Source guide: PDF page(s) 51.
This item is flagged for content review.
Open this question’s page →Application architecture
✓ Correct answer
Deferral retains a received message for later retrieval once prerequisites exist. Scheduling controls initial availability and is a distinct mechanism, Receive and Delete does not retain recoverable work, and advancing a stream checkpoint is not deferred Service Bus message retrieval. Source guide: PDF page(s) 51.
This item is flagged for content review.
Open this question’s page →Application architecture
✓ Correct answer
A transactional outbox atomically records business state and publication intent in the database, enabling later retries. Sending first can publish an order that never commits, broker transactions do not automatically include arbitrary SQL, and TTL does not preserve missing publication intent. Source guide: PDF page(s) 51.
This item is flagged for content review.
Open this question’s page →Application architecture
✓ Correct answers
Poison handling and claim-check references fit Queue Storage's simpler model and payload limits. Storage queues do not expose Service Bus sessions or identical dead-letter infrastructure; encoding overhead can reduce the effective payload budget. Source guide: PDF page(s) 51-52.
This item is flagged for content review.
Open this question’s page →Application architecture
✓ Correct answer
Event Grid routes discrete change notifications to interested handlers, using references to source objects. Event Hubs targets retained high-volume streams and does not guarantee global order, APIM mediates API calls rather than durable event publication, and App Configuration manages settings. Source guide: PDF page(s) 49, 51.
This item is flagged for content review.
Open this question’s page →Application architecture
✓ Correct answers
Stable identifiers and order-aware state handling address at-least-once and non-guaranteed ordering. Retry duration does not create global order, early acknowledgment can lose work, and large objects should be referenced rather than embedded. Source guide: PDF page(s) 51.
This item is flagged for content review.
Open this question’s page →Application architecture
✓ Correct answer
Event Grid namespaces support a pull model with receive and settlement operations. Ordinary push delivery is not the requested consumer-driven pull semantics, APIM keys identify subscriptions rather than event locks, and DNS routing does not consume events. Source guide: PDF page(s) 51.
This item is flagged for content review.
Open this question’s page →Application architecture
✓ Correct answers
Event Hubs supplies retained stream partitions and independent consumption views; checkpoints after durable work allow safe restart. Competing queue consumers divide messages, early checkpointing can skip unprocessed events, and Event Grid notifications are not an unlimited retained replay log. Source guide: PDF page(s) 51.
This item is flagged for content review.
Open this question’s page →Application architecture
✓ Correct answer
Partition ownership and hot keys constrain useful parallelism; extra consumers cannot automatically create partition capacity. Portal users are unrelated, independent groups do not share one global checkpoint by definition, and workers do not each cause an automatic partition. Source guide: PDF page(s) 51.
This item is flagged for content review.
Open this question’s page →Application architecture
✓ Correct answer
An advanced checkpoint can cause restart to move beyond lost results. It is a recorded reading position rather than a distributed database transaction, does not delete independent consumer groups, and partition grouping does not rebuild uncommitted business results. Source guide: PDF page(s) 51.
This item is flagged for content review.
Open this question’s page →Application architecture
✓ Correct answer
Capture writes the stream to supported storage for archival and batch use, while live lag still needs monitoring. It does not make external analytics transactional; duplicate detection manages repeated broker sends and configuration snapshots store settings rather than telemetry. Source guide: PDF page(s) 51.
This item is flagged for content review.
Open this question’s page →Application architecture
✓ Correct answer
APIM combines API publication, gateway policies, usage controls, and a developer portal. Front Door focuses on global web delivery, Application Gateway on regional HTTP routing and WAF, and slots on release staging; none alone supplies the requested API management capability set. Source guide: PDF page(s) 52.
This item is flagged for content review.
Open this question’s page →Application architecture
✓ Correct answers
Token validation must establish its intended API, issuer, lifetime, and authorization claims. A valid signature alone does not grant a different audience, subscription keys do not fully authenticate a sensitive user, and backend access remains protected. Source guide: PDF page(s) 52.
This item is flagged for content review.
Open this question’s page →Application architecture
✓ Correct answer
A managed identity obtains supported backend credentials without embedded passwords and still needs permissions. Subscription keys do not become universal Entra passwords, service tags represent network prefixes, and public IP reachability is not identity authorization. Source guide: PDF page(s) 52.
This item is flagged for content review.
Open this question’s page →Application architecture
✓ Correct answer
Standard v2 outbound integration addresses private backend reachability while gateway ingress remains public. Developer lacks the production SLA, a cache is not a private tunnel, and Premium v2's name does not imply classic feature parity. Source guide: PDF page(s) 52.
This item is flagged for content review.
Open this question’s page →Application architecture
✓ Correct answer
Premium classic is the supported candidate for these classic capabilities. Premium v2 does not automatically include them, Developer is a non-production-SLA test tier rather than this multiregion production option, and private backend integration is distinct from multiregion deployment. Source guide: PDF page(s) 52.
This item is flagged for content review.
Open this question’s page →Application architecture
✓ Correct answers
Rate limiting controls burst frequency and quota expresses longer usage allowance. Execution timeout controls processing lifetime, geographic DNS selects endpoints, and image tags select deployments rather than enforcing API consumption limits. Source guide: PDF page(s) 52.
This item is flagged for content review.
Open this question’s page →Application architecture
✓ Correct answer
Consumption lacks built-in internal caching. Cache capabilities differ by tier, quotas govern usage rather than creating cache infrastructure, and a portal does not enable an unsupported gateway cache. Source guide: PDF page(s) 52-53.
This item is flagged for content review.
Open this question’s page →Application architecture
✓ Correct answer
Cache-aside loads from the source on a miss and caches reusable data. A miss only describes cache state, a permanent blank can hide valid source data, and process memory is not a suitable durable authoritative replacement. Source guide: PDF page(s) 53.
This item is flagged for content review.
Open this question’s page →Application architecture
✓ Correct answer
Cache invalidation or update aligns the reusable copy with authoritative changes. More instances can create more stale local copies, a longer TTL extends staleness, and in-process caches are not automatically shared or synchronized. Source guide: PDF page(s) 53.
This item is flagged for content review.
Open this question’s page →Application architecture
✓ Correct answers
Keys must include security-sensitive variation and only safely reusable data should be cached. Longer TTL prolongs disclosure, a network prefix tag does not supply confidentiality or identity, and identical URLs can produce different authorized data. Source guide: PDF page(s) 53.
This item is flagged for content review.
Open this question’s page →Application architecture
✓ Correct answer
Managed Redis is the current managed Redis direction. The legacy Basic and Enterprise families have announced retirement and creation restrictions that require migration planning, while App Configuration manages settings rather than serving as Redis-compatible data caching. Source guide: PDF page(s) 53.
This item is flagged for content review.
Open this question’s page →Application architecture
✓ Correct answer
Current guidance removed the planned block for qualifying existing Basic/Standard/Premium customers while retaining tier-specific retirement and new-customer/cloud rules. It did not delete every cache in October 2026, Enterprise and Basic have different dates, and eligibility restrictions are not universally absent. Source guide: PDF page(s) 53.
This item is flagged for content review.
Open this question’s page →Application architecture
✓ Correct answers
Coalescing, staggered expiry, prewarming, and bounded fallback limit a miss storm. Unlimited fallback and more independent requests increase pressure; indefinite retention ignores freshness and does not restore missing cache data after restart. Source guide: PDF page(s) 53.
This item is flagged for content review.
Open this question’s page →Application architecture
✓ Correct answer
App Configuration centralizes settings and feature flags with supported refresh. Key Vault primarily protects secrets; independent deployment copies and image-baked files need releases and coordination rather than providing centralized code-independent enablement. Source guide: PDF page(s) 53.
This item is flagged for content review.
Open this question’s page →Application architecture
✓ Correct answer
A snapshot is an immutable selected configuration set suitable for repeatable release configuration. An unversioned mutable key cannot preserve the set, APIM subscription keys govern API subscription access, and a delivery lock controls message reception. Source guide: PDF page(s) 53.
This item is flagged for content review.
Open this question’s page →Application architecture
✓ Correct answers
Secret references require both authorized Key Vault retrieval and a working network/DNS path. Configuration permissions are separate, feature flags do not authorize secrets, and a reference is not automatically an embedded plaintext value. Source guide: PDF page(s) 53.
This item is flagged for content review.
Open this question’s page →Application architecture
✓ Correct answer
Server authorization protects direct endpoint calls. Hiding navigation only affects presentation, flag-editor rights govern configuration modification rather than endpoint use, and a snapshot preserves values without granting caller permissions. Source guide: PDF page(s) 53.
This item is flagged for content review.
Open this question’s page →Application architecture
✓ Correct answer
Bicep is the Azure-native declarative language compiling to ARM templates. Terraform uses provider/state semantics, while sequential CLI commands and manual portal steps are not the requested declarative module language. Source guide: PDF page(s) 54.
This item is flagged for content review.
Open this question’s page →Application architecture
✓ Correct answer
Secured shared state and locking coordinate resource tracking and protect sensitive content. Public plaintext state exposes secrets, divergent local state permits conflicting changes, and DNS TTL does not serialize infrastructure operations. Source guide: PDF page(s) 54.
This item is flagged for content review.
Open this question’s page →Application architecture
✓ Correct answers
Federated or managed identity reduces embedded credentials, and one immutable artifact preserves release identity. Rebuilding creates unverified differences, permanent admin credentials increase exposure, and infrastructure success does not prove application behavior. Source guide: PDF page(s) 54.
This item is flagged for content review.
Open this question’s page →Application architecture
✓ Correct answer
Canary deliberately exposes a small traffic share and expands on health evidence. The stated all-at-once blue-green switch does not provide the requested initial percentage, unsafe rolling replacement ignores readiness and capacity, and swaps cannot undo arbitrary database changes. Source guide: PDF page(s) 54.
This item is flagged for content review.
Open this question’s page →Application architecture
✓ Correct answer
Expand-and-contract retains compatible schema until the old version is retired. Traffic rollback does not restore removed data, duplicate environments do not make their shared schema reversible, and rate controls do not repair incompatible contracts. Source guide: PDF page(s) 54.
This item is flagged for content review.
Open this question’s page →Network design
✓ Correct answer
Ordinary VNet peering requires nonoverlapping address spaces. Gateway transit and broader routes do not remove conflicting destinations, and circuit bandwidth affects throughput rather than address ambiguity. Source guide: PDF page(s) 55.
This item is flagged for content review.
Open this question’s page →Network design
✓ Correct answer
Two hub peerings do not create automatic transit between spokes. Peering does carry supported private IP traffic, gateway transit is a separate shared-gateway feature, and same-region spokes can use direct peering or routed hub transit without requiring global peering. Source guide: PDF page(s) 55.
This item is flagged for content review.
Open this question’s page →Network design
✓ Correct answer
Sharing the hub gateway requires compatible gateway-transit and remote-gateway settings. Separate spoke gateways contradict the sharing requirement, DNS links do not establish packet transit, and UDRs alone do not replace the required peering configuration. Source guide: PDF page(s) 55.
This item is flagged for content review.
Open this question’s page →Network design
✓ Correct answer
Virtual WAN provides managed hubs and supported branch/VNet connections, while routing policies still determine reachability. Ordinary peering is nontransitive, Traffic Manager answers DNS, and NAT Gateway supplies subnet egress rather than private global WAN tunnels. Source guide: PDF page(s) 55-56.
This item is flagged for content review.
Open this question’s page →Network design
✓ Correct answer
NAT supplies controlled public egress addresses. An internal load balancer alone does not establish explicit egress, Bastion serves administrative access, and implicit default addresses are not guaranteed predictable customer-controlled sources. Source guide: PDF page(s) 55.
This item is flagged for content review.
Open this question’s page →Network design
✓ Correct answer
The selected route directs traffic to the firewall; NAT attachment neither overrides nor automatically removes that UDR. Stale DNS does not make NAT replace the route, and private subnets can use supported explicit egress. Source guide: PDF page(s) 55-57.
This item is flagged for content review.
Open this question’s page →Network design
✓ Correct answer
The API-dependent new-VNet default requires explicit outbound connectivity for private VMs. Existing VNets are not automatically converted, an inbound allow rule does not supply egress translation or routing, and Basic Load Balancer is retired. Source guide: PDF page(s) 56.
This item is flagged for content review.
Open this question’s page →Network design
✓ Correct answers
Explicit connectivity establishes the outbound path, and deallocation can be required to clear previous NIC-level default assignments. The private flag does not create NAT, the change is not universal existing-network conversion, and DNS forwarding cannot replace egress. Source guide: PDF page(s) 56.
This item is flagged for content review.
Open this question’s page →Network design
✓ Correct answer
Connection churn and concurrency can exhaust translation capacity, so reuse and measured port pressure matter. Inbound permissions alone do not characterize SNAT, DNS caching does not allocate ports, and probes cannot prove unlimited connection capacity. Source guide: PDF page(s) 55-56.
This item is flagged for content review.
Open this question’s page →Network design
✓ Correct answer
Site-to-site VPN provides the network-to-network IPsec/IKE tunnel. Point-to-site targets individual clients, ExpressRoute is private connectivity rather than this internet tunnel and is not automatically end-to-end encrypted, and Traffic Manager performs DNS endpoint selection. Source guide: PDF page(s) 56.
This item is flagged for content review.
Open this question’s page →Network design
✓ Correct answer
Point-to-site connects individual supported clients with appropriate authentication. A site-to-site appliance is a different network-to-network model, Global Reach connects circuits rather than laptop VPN clients, and NAT Gateway does not provide unsolicited inbound administration. Source guide: PDF page(s) 56.
This item is flagged for content review.
Open this question’s page →Network design
✓ Correct answer
Local network gateway represents remote VPN device information and prefixes. Virtual network gateway terminates Azure's tunnel, GatewaySubnet supplies its local address space, and peering connects VNets rather than defining a remote appliance. Source guide: PDF page(s) 56.
This item is flagged for content review.
Open this question’s page →Network design
✓ Correct answers
Private transport and encryption are separate requirements. TLS and supported IPsec can protect the required traffic scope; redundant connections improve availability without encrypting payloads, MACsec covers the supported physical-link segment, and BGP exchanges routes rather than encrypting application content. Source guide: PDF page(s) 56-57.
This item is flagged for content review.
Open this question’s page →Network design
✓ Correct answer
Private peering is intended for on-premises-to-Azure VNet routing. Microsoft peering reaches supported Microsoft public services under requirements, VNet peering is not the provider circuit, and DNS links do not exchange BGP prefixes. Source guide: PDF page(s) 56.
This item is flagged for content review.
Open this question’s page →Network design
✓ Correct answers
Resilience spans the full physical and logical path, including devices, circuits, locations, gateways, routes, and surviving capacity. Circuit redundancy alone does not remove correlated upstream failures, one public check does not validate hybrid paths, and BGP does not eliminate routing or provide encryption. Source guide: PDF page(s) 56-57.
This item is flagged for content review.
Open this question’s page →Network design
✓ Correct answer
FastPath optimizes supported data paths while retaining the gateway's route exchange role. It does not eliminate gateway control requirements or DNS, and eligibility differs by circuit and destination features. Source guide: PDF page(s) 57.
This item is flagged for content review.
Open this question’s page →Network design
✓ Correct answer
Global Reach links supported circuits for on-premises site communication. VNet peering joins virtual networks rather than the external circuits, Front Door handles supported HTTP origin connectivity, and NAT Gateway provides subnet public egress rather than circuit transit. Source guide: PDF page(s) 57.
This item is flagged for content review.
Open this question’s page →Network design
✓ Correct answers
Backup readiness includes usable capacity and complete application routing, DNS, and security behavior. Tunnel status alone does not validate those, a diagram does not establish a working path, and failover does not require removing application confidentiality. Source guide: PDF page(s) 57.
This item is flagged for content review.
Open this question’s page →Network design
✓ Correct answer
Longest matching prefix ordinarily comes before equal-prefix route-type precedence, so the /16 is more specific than /0. UDR priority is not a universal override of more specific routes, private prefixes can be learned by BGP, and creation order is not the selection rule. Source guide: PDF page(s) 57.
This item is flagged for content review.
Open this question’s page →Network design
✓ Correct answer
For equal applicable prefixes, ordinary precedence is UDR, BGP, then system. Dynamic routing is not universally first, system routes can often be overridden by supported UDRs, and NSG priority selects filtering rules rather than routes. Source guide: PDF page(s) 57.
This item is flagged for content review.
Open this question’s page →Network design
✓ Correct answer
Service-endpoint next-hop routes are an important routing exception; the traffic path must be redesigned or assessed accordingly. Generic longest-prefix claims cannot erase that exception, NAT does not transform endpoints, and NSGs filter traffic without rewriting route types. Source guide: PDF page(s) 57.
This item is flagged for content review.
Open this question’s page →Network design
✓ Correct answer
The documented Virtual network gateway UDR target is for VPN rather than ExpressRoute gateways. Support cannot be assumed across gateway types, adding a private endpoint does not change the UDR capability, and filtering priority cannot enable an unsupported route target. Source guide: PDF page(s) 57.
This item is flagged for content review.
Open this question’s page →Network design
✓ Correct answers
A usable NVA path needs forwarding, actual routes, allowed policy, and return-path coherence. The route table's existence does not prove appliance behavior, DNS naming is not forwarding configuration, and billing discounts do not route packets. Source guide: PDF page(s) 57.
This item is flagged for content review.
Open this question’s page →Network design
✓ Correct answer
Stateful inspection can fail when only one direction follows the expected session path. Effective routing and packet evidence identify the inconsistency; permissive filtering does not fix asymmetry, DNS TTL does not synchronize firewall state, and VM size does not deterministically correct routes. Source guide: PDF page(s) 57.
This item is flagged for content review.
Open this question’s page →Network design
✓ Correct answers
Private endpoints and DNS establish the private path; public exposure requires separate service settings. Private Link alone does not universally disable public access, network addresses do not authorize data access, and service endpoints retain public service addressing. Source guide: PDF page(s) 57-58.
This item is flagged for content review.
Open this question’s page →Network design
✓ Correct answer
File and blob are separate supported endpoint targets with corresponding DNS. A blob endpoint does not cover every subresource, a filtering rule does not create missing Private Link connectivity, and renaming the NIC does not change its service target. Source guide: PDF page(s) 57-58.
This item is flagged for content review.
Open this question’s page →Network design
✓ Correct answer
Service endpoints extend supported subnet identity over the backbone without assigning the destination a private VNet NIC. Private endpoint addressing is a different model, on-premises private access is not automatically supplied, and valid application permissions remain required. Source guide: PDF page(s) 57-58.
This item is flagged for content review.
Open this question’s page →Network design
✓ Correct answers
Private records and zone access plus on-premises-to-Azure forwarding make the service name resolve to the endpoint IP. Outbound resolver endpoints handle the opposite selected-query direction, direct IP can break TLS and SDK expectations, and VPN reachability does not automatically configure DNS. Source guide: PDF page(s) 58.
This item is flagged for content review.
Open this question’s page →Network design
✓ Correct answer
Normal hostnames retain the certificate identity and SDK contract while DNS maps to the private endpoint. Disabling validation weakens confidentiality assurance, an arbitrary IP does not automatically match the certificate, and NSGs cannot validate TLS hostnames. Source guide: PDF page(s) 58.
This item is flagged for content review.
Open this question’s page →Network design
✓ Correct answer
Outbound endpoints and rulesets forward selected Azure queries externally. Inbound endpoints serve incoming queries, zone links expose records rather than forwarding all queries, and an empty shadow zone cannot resolve on-premises records. Source guide: PDF page(s) 58.
This item is flagged for content review.
Open this question’s page →Network design
✓ Correct answer
Zone visibility and resolver paths can differ between VNets even with working routing. Packet permissions and bandwidth do not correct DNS, and private endpoint creation does not universally link its records to every VNet. Source guide: PDF page(s) 58.
This item is flagged for content review.
Open this question’s page →Network design
✓ Correct answer
NSGs evaluate lower-numbered priorities first and apply the first match. Higher numbers are later, allow does not universally override deny, and matching rules are not merged. Source guide: PDF page(s) 58-59.
This item is flagged for content review.
Open this question’s page →Network design
✓ Correct answer
Both applicable NSGs participate in filtering, so a deny at either scope can block the flow. Neither general subnet precedence nor automatic NIC omission applies, and egress translation does not override NSG permissions. Source guide: PDF page(s) 59.
This item is flagged for content review.
Open this question’s page →Network design
✓ Correct answer
ASGs group selected NICs by role. Service tags are maintained prefix sets rather than arbitrary NIC membership, VirtualNetwork is broader than this role distinction, and subnet names do not automatically create application security groups. Source guide: PDF page(s) 59.
This item is flagged for content review.
Open this question’s page →Network design
✓ Correct answers
WAF inspects supported HTTP requests, while Firewall/NVA handles centralized network and application traffic policies. NSGs filter network attributes rather than HTTP bodies, NAT performs outbound translation rather than full inspection, and WAF does not provide universal UDP security. Source guide: PDF page(s) 59.
This item is flagged for content review.
Open this question’s page →Network design
✓ Correct answer
Bastion supplies managed secure administrative access. Direct public port forwarding is a different exposed model, NAT is outbound-only, and Private Link connects supported service targets rather than universally administering arbitrary VMs. Source guide: PDF page(s) 59.
This item is flagged for content review.
Open this question’s page →Network design
✓ Correct answer
The controls operate on different attack classes and should be selected by traffic and supported scope. WAF is not universal network flood protection, DDoS mitigation is not application authorization, and service tags do not inspect malicious bodies. Source guide: PDF page(s) 59.
This item is flagged for content review.
Open this question’s page →Network design
✓ Correct answer
An internal Standard Load Balancer provides supported Layer 4 private distribution. Application Gateway and Front Door target HTTP/HTTPS application delivery, while Traffic Manager answers DNS rather than proxying regional transport flows. Source guide: PDF page(s) 59-60.
This item is flagged for content review.
Open this question’s page →Network design
✓ Correct answer
Application Gateway v2 supplies regional Layer 7 routing, TLS termination, health probes, and WAF options. Standard Load Balancer is Layer 4, Traffic Manager does not terminate TLS, and NAT Gateway is an outbound translator. Source guide: PDF page(s) 59-60.
This item is flagged for content review.
Open this question’s page →Network design
✓ Correct answers
Front Door Premium supports private origin connectivity and managed WAF rules, while origin restriction preserves the intended security entry. Standard does not have these Premium capabilities, Traffic Manager does not proxy or cache HTTP, and unrestricted origins can bypass edge policy. Source guide: PDF page(s) 59-60.
This item is flagged for content review.
Open this question’s page →Network design
✓ Correct answer
Traffic Manager's DNS answers are subject to caching and existing connections; health and TTL behavior influence observed convergence. It is not an in-path packet proxy, does not terminate TLS, and DNS routing does not roll back database state. Source guide: PDF page(s) 60.
This item is flagged for content review.
Open this question’s page →Network design
✓ Correct answer
Global Load Balancer provides supported cross-region Layer 4 distribution over regional public Standard Load Balancers. Front Door and Application Gateway are HTTP application-delivery services, and an internal regional load balancer does not automatically gain a global public frontend. Source guide: PDF page(s) 59-60.
This item is flagged for content review.
Open this question’s page →Migration design
✓ Correct answer
Rehosting preserves the application pattern with limited change and can fit the deadline. Rebuilding or unassessed replacement introduces larger changes; retirement is inappropriate while the application provides required value. Source guide: PDF page(s) 61.
This item is flagged for content review.
Open this question’s page →Migration design
✓ Correct answer
Replatforming changes hosting with limited application changes. Rearchitecting changes structure, retaining keeps the current environment, and rebuilding creates a new application. Source guide: PDF page(s) 61.
This item is flagged for content review.
Open this question’s page →Migration design
✓ Correct answer
Rearchitecting changes application structure. Rehosting preserves it, retaining leaves it in place, and retiring removes a workload after business and dependency checks. Source guide: PDF page(s) 61.
This item is flagged for content review.
Open this question’s page →Migration design
✓ Correct answer
Retirement requires evidence that removal is safe and obligations are satisfied. Regional copies, a larger VM, or an unrelated queue add work without establishing that decommissioning is appropriate. Source guide: PDF page(s) 61.
This item is flagged for content review.
Open this question’s page →Migration design · Governance and compliance
✓ Correct answer
Landing-zone prerequisites are part of production readiness. Replication alone proves neither secure access nor recoverability. Deferring essential controls or using shared permanent privilege undermines a controlled migration. Source guide: PDF page(s) 61.
This item is flagged for content review.
Open this question’s page →Migration design
✓ Correct answer
Discovery identifies assets; assessment evaluates readiness and sizing; migration copies or replicates them. Inventory does not start VMs, install a PaaS application, or complete cutover. Source guide: PDF page(s) 62.
This item is flagged for content review.
Open this question’s page →Migration design
✓ Correct answer
Dependency analysis reveals the working application unit and supports coherent wave grouping. Names and purchase dates do not define runtime dependencies; forced separation can leave a workload across an unsuitable network path. Source guide: PDF page(s) 62.
This item is flagged for content review.
Open this question’s page →Migration design
✓ Correct answer
Sizing must reflect representative business demand and adequate evidence. Quiet averages can hide peaks, aggressive downsizing is unsafe with low confidence, and omitting a real dependency makes the assessment incomplete. Source guide: PDF page(s) 62.
This item is flagged for content review.
Open this question’s page →Migration design
✓ Correct answer
As-on-premises sizing preserves allocation more directly. Performance-based sizing uses measured utilization; transaction benchmarking and rehearsal are distinct validation activities. Source guide: PDF page(s) 62.
This item is flagged for content review.
Open this question’s page →Migration design
✓ Correct answers
Identity and application dependencies are necessary to make the workload function after migration. Display details and logos do not establish readiness; identical public IPs are neither generally available nor a universal requirement. Source guide: PDF page(s) 62.
This item is flagged for content review.
Open this question’s page →Migration design
✓ Correct answer
Replication is a transfer mechanism, not a complete readiness test. Dependency behavior, transactions, backups, and ownership still need validation. Booting alone is insufficient, and deletion must wait for acceptance and rollback conditions. Source guide: PDF page(s) 62.
This item is flagged for content review.
Open this question’s page →Migration design
✓ Correct answer
Isolation must prevent duplicate writers and real emails or payments while permitting representative validation. Production connectivity risks side effects; omitting identity validation or all rehearsal leaves essential risks untested. Source guide: PDF page(s) 62.
This item is flagged for content review.
Open this question’s page →Migration design
✓ Correct answers
Final synchronization and dependency-aware startup support a controlled switch. Uncoordinated dual writers can diverge; premature routing exposes unready services; deleting backups removes recovery options. Source guide: PDF page(s) 62-63.
This item is flagged for content review.
Open this question’s page →Migration design
✓ Correct answer
New target writes must be retained or reconciled before returning traffic to the source. DNS changes are possible but do not synchronize state; reverse replication is not universal; deleting data is not a valid blanket response. Source guide: PDF page(s) 63.
This item is flagged for content review.
Open this question’s page →Migration design · Application architecture
✓ Correct answers
External state and properly managed configuration reduce dependence on VM-local assumptions. Sticky routing does not make local data durable, source control is inappropriate for secrets, and instance filesystems are not automatically shared. Source guide: PDF page(s) 63.
This item is flagged for content review.
Open this question’s page →Migration design
✓ Correct answer
Azure VMware Solution is relevant when preserving the VMware environment and tooling is a justified constraint. Azure VM rehosting can move applications but does not preserve the same VMware operating environment. App Service replatforming and AKS containerization require application changes and are not a VMware environment destination. Source guide: PDF page(s) 63.
This item is flagged for content review.
Open this question’s page →Migration design · Relational data
✓ Correct answer
Target capabilities and operating requirements constrain the migration workflow. Azure SQL Database, Managed Instance, and SQL on VMs differ; table copies omit jobs and behavior; removal without assessment can break the application. Source guide: PDF page(s) 63.
This item is flagged for content review.
Open this question’s page →Migration design
✓ Correct answer
Current DMS does not provide online migration to Azure SQL Database. A different supported approach or suitable target must be evaluated against requirements. Names do not change service capabilities, and schema preparation does not eliminate data synchronization or cutover. Source guide: PDF page(s) 63.
This item is flagged for content review.
Open this question’s page →Migration design
✓ Correct answer
Online reduces downtime but still needs a final consistent synchronization and switch. It does not guarantee zero outage, migrate every external object, or justify deleting recovery options. Source guide: PDF page(s) 63.
This item is flagged for content review.
Open this question’s page →Migration design
✓ Correct answer
DMS consumes prepared backups in supported backup-based workflows. The team must maintain the chain and access requirements. Diagnostic settings, DNS, and target sizing do not create source backups or replace the log chain. Source guide: PDF page(s) 63.
This item is flagged for content review.
Open this question’s page →Migration design
✓ Correct answer
Current DMS can handle supported missing schema; supported project tooling is another preparation path. The object support list and server dependencies still require review, and an empty database establishes no application compatibility. Source guide: PDF page(s) 63.
This item is flagged for content review.
Open this question’s page →Migration design
✓ Correct answer
Migration validation must cover the application and surrounding behavior. Names, transfer screenshots, and portal access do not verify correctness, jobs, application authorization, or database performance. Source guide: PDF page(s) 63.
This item is flagged for content review.
Open this question’s page →Migration design
✓ Correct answer
Azure Data Studio retired February 28, 2026. Use supported replacements and current scenario guidance. Retirement of one tool does not invalidate every DMS scenario or justify an unrelated data-model change. Source guide: PDF page(s) 63.
This item is flagged for content review.
Open this question’s page →Migration design
✓ Correct answer
Enumeration, metadata work, and operations per second can limit many-small-file migrations. Advertised bandwidth alone ignores those effects. Database CPU sizing does not identify the file-copy bottleneck. Storage configuration may affect performance, but redundancy alone does not explain or measure per-file overhead. Source guide: PDF page(s) 64.
This item is flagged for content review.
Open this question’s page →Migration design
✓ Correct answer
Storage Mover supplies managed projects, endpoints, repeatable jobs, and monitoring for supported migration paths. AzCopy is useful for command-line copies but lacks that same managed project workflow. File Sync addresses an ongoing cache/tiering architecture, which is not requested. Data Box is for physical bulk transfer and is not the requested managed online job orchestration. Source guide: PDF page(s) 64.
This item is flagged for content review.
Open this question’s page →Migration design
✓ Correct answer
The current scenario matrix, agent requirements, cloud availability, status, and fidelity guarantees govern implementation. A universal protocol-pair assumption is unsafe. File extensions do not establish protocol compatibility, and old notes can omit newer supported paths. Source guide: PDF page(s) 64.
This item is flagged for content review.
Open this question’s page →Migration design
✓ Correct answer
AzCopy most directly supplies the requested command-line copy on supported storage paths. Storage Mover addresses managed job orchestration rather than this command-line task. File Sync serves permanent Windows caching and tiering. Data Box serves physical bulk transfer rather than the requested online command-line copy. Source guide: PDF page(s) 64.
This item is flagged for content review.
Open this question’s page →Migration design
✓ Correct answer
Metadata preservation depends on source, target, and supported options. Successful byte copying alone does not establish permissions or timestamps; public access or blanket ACL replacement contradicts fidelity requirements. Source guide: PDF page(s) 64.
This item is flagged for content review.
Open this question’s page →Migration design
✓ Correct answer
File Sync fits an ongoing Windows Server cache with Azure Files and cloud tiering. AzCopy and Storage Mover can transfer data but do not supply that persistent caching service. Data Box is a bulk transfer device, not a continuous cache/tiering layer. Source guide: PDF page(s) 64.
This item is flagged for content review.
Open this question’s page →Migration design
✓ Correct answer
Physical bulk transfer can address bandwidth limits, but logistics and subsequent changes still require a consistency plan. Ignoring device timing or using tags or premature DNS changes does not transfer a usable dataset. Source guide: PDF page(s) 64.
This item is flagged for content review.
Open this question’s page →Migration design
✓ Correct answer
2,000,000 MB / 200 MB/s = 10,000 s, approximately 2.78 hours. Other values use incorrect division. A production plan must additionally allow for retries, enumeration, changed data, and validation. Source guide: PDF page(s) 69.
This item is flagged for content review.
Open this question’s page →Migration design
✓ Correct answer
Decommissioning requires agreed acceptance and recovery and retention conditions. A VM or one HTTP response does not establish those conditions; cost reduction must not bypass them. Source guide: PDF page(s) 64.
This item is flagged for content review.
Open this question’s page →Integrated architecture scenarios · Relational data · High availability · Compute design
✓ Correct answer
Availability depends on the complete journey, including the data tier and surviving capacity. Extra frontends do not fix a failed indispensable database; static probes can hide dependency failure; a component SLA is not the journey target. Source guide: PDF page(s) 65.
This item is flagged for content review.
Open this question’s page →Integrated architecture scenarios · Relational data · Backup and disaster recovery
✓ Correct answers
Asynchronous lag can lose recent writes, and recovery must restore a working application with capacity and connectivity. Async replication does not guarantee zero loss or reverse propagated deletion, and failover authority remains necessary. Source guide: PDF page(s) 65.
This item is flagged for content review.
Open this question’s page →Integrated architecture scenarios · Identity and access · Network design · Object, file, and NoSQL data
✓ Correct answer
The managed identity needs appropriate Blob data authorization at the correct scope. Management-plane configuration rights are not an automatic Blob data-role grant. DNS and routing are already working in this scenario; changing an alias does not supply permissions. Microsoft Graph permissions authorize a different API, not access to the blobs. Source guide: PDF page(s) 65.
This item is flagged for content review.
Open this question’s page →Integrated architecture scenarios · Identity and access · Application architecture
✓ Correct answers
App Configuration suits nonsecret settings; Key Vault suits secrets; managed identity can eliminate supported stored Azure credentials. Flags, source images, and shared permanent high privilege are inappropriate secret or identity designs. Source guide: PDF page(s) 65.
This item is flagged for content review.
Open this question’s page →Integrated architecture scenarios · Application architecture · Integration and analytics
✓ Correct answer
Event Hubs supplies a retained partitioned stream with independent consumer positions. One competing queue does not give both teams independent full streams, an overwritten cache loses history, and notification delivery is not the required retained-log design. Source guide: PDF page(s) 66.
This item is flagged for content review.
Open this question’s page →Integrated architecture scenarios · Application architecture
✓ Correct answer
Service Bus offers the required business-messaging mechanisms, including sessions for related ordering and completion/dead-letter handling. Event Hubs ordering and checkpoints are stream-processing mechanisms rather than the required queue settlement model. Queue Storage requires application handling and does not supply the same native sessions/dead-letter features. Event Grid notifications do not provide the specified ordered transactional business queue. Source guide: PDF page(s) 66.
This item is flagged for content review.
Open this question’s page →Integrated architecture scenarios · Application architecture
✓ Correct answer
Redelivery after a crash can repeat the external side effect. Application idempotency or coordinated transaction design addresses that window. Acknowledgement is incomplete, broker deduplication is not a universal side-effect guarantee, and longer retention does not prevent duplicate updates. Source guide: PDF page(s) 66, 69.
This item is flagged for content review.
Open this question’s page →Integrated architecture scenarios · Backup and disaster recovery · Relational data
✓ Correct answer
Dependency consistency and RPO can differ; database-native or another supported mechanism may be required. The looser target cannot automatically satisfy the tighter one, boot time is not service recovery, and replication does not replace retained recovery points. Source guide: PDF page(s) 66.
This item is flagged for content review.
Open this question’s page →Integrated architecture scenarios · Backup and disaster recovery · Network design
✓ Correct answer
Recovery orchestration must restore dependency readiness and validate acceptable service. Boot time, a static page, and premature routing do not prove the user journey is recovered. Source guide: PDF page(s) 66.
This item is flagged for content review.
Open this question’s page →Integrated architecture scenarios · Backup and disaster recovery
✓ Correct answers
Isolation and controlled dependencies prevent interference while allowing useful testing. Premature production routing and live side effects defeat the requirement; omitting identity and authorization leaves recovery readiness unproven. Source guide: PDF page(s) 66.
This item is flagged for content review.
Open this question’s page →Integrated architecture scenarios · Backup and disaster recovery
✓ Correct answer
The steps total 45 minutes, leaving 15 minutes of the 60-minute RTO. The other values confuse elapsed and remaining time or omit steps. Representative tests still need to validate dependencies and timings. Source guide: PDF page(s) 68.
This item is flagged for content review.
Open this question’s page →Integrated architecture scenarios · Backup and disaster recovery
✓ Correct answer
Typical lag is not a worst-case recovery guarantee. Validate replication under stress and the usable state across dependencies. A quiet average, frontend count, or DNS TTL cannot establish the data-loss target. Source guide: PDF page(s) 68.
This item is flagged for content review.
Open this question’s page →Integrated architecture scenarios · Monitoring and logging
✓ Correct answer
Instrumentation covers app traces, AMA/DCRs guest telemetry, and diagnostic settings supported platform categories. An agent cannot replace every PaaS diagnostic setting; database settings do not instrument a VM app; a workspace alone collects none of these required configured paths. Source guide: PDF page(s) 68.
This item is flagged for content review.
Open this question’s page →Integrated architecture scenarios · Network design · Object, file, and NoSQL data
✓ Correct answer
Hybrid clients need a supported DNS resolution path, such as Private Resolver or forwarding, and private network reachability. Contributor does not fix DNS resolution and does not automatically grant Blob data permissions; public anonymous access is not required; zone placement is irrelevant. Source guide: PDF page(s) 68.
This item is flagged for content review.
Open this question’s page →Integrated architecture scenarios · Migration design
✓ Correct answer
Workload-specific strategies meet differing requirements and deadlines. Universal rebuilding, indiscriminate copying, and tool-first planning ignore value, compatibility, and operational constraints. Source guide: PDF page(s) 67.
This item is flagged for content review.
Open this question’s page →Published for public study on StudyByteLearn with the maintainer's permission. No permission for further redistribution is granted. Rights in the supplied source material remain with their respective holders. · Updated 2026-10-20
Created by Codex with three authoring subagents on 2026-10-20 from the user-supplied AZ-305 Study Guide.pdf (103 pages, reviewed 20 October 2026), which the user reports was already checked and validated. All assigned technical chapters, four worked cases, and six exercises were read. Official objectives and selected current service details were checked using Microsoft Learn MCP. Authors self-reviewed generated keys and explanations; the final bank received structural, duplicate, coverage, and scoring validation. Newly generated items remain needs_review because the prior source validation does not establish independent human review of these items. See README and references for the precise review scope and reference-maintenance notes.