AZ-900 Describe Azure management and governance Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  That data will never be lost under any circumstances

  Why it's wrong here

  Azure Storage SLAs focus on availability (uptime), not an absolute promise that data will never be lost. Durability is a separate architectural property addressed by redundancy options like LRS/GRS, and even the commonly cited “11 nines of durability” is an annual expected probability, not a guarantee. Furthermore, the SLA explicitly excludes data loss incidents caused by customer actions, force majeure, or other scenarios, so the statement is false.

• ✓

  The percentage of time the storage service is available for read/write requests

  Why this is correct

  The Azure Storage SLA defines a monthly availability percentage (e.g., 99.9% for standard general-purpose v2 accounts, 99.99% for some premium or geo-redundant configurations) that measures the service’s ability to successfully handle authenticated read and write requests. The percentage is calculated by dividing the total number of successful requests by the total number of attempted requests over the billing month. If the observed availability falls below the SLA percentage, and the shortfall is not due to excluded causes, customers can file a claim for service credits, which are a percentage of the service fee.

• ✗

  That data will be retrieved within 5 milliseconds

  Why it's wrong here

  Availability SLAs say how often requests are successfully processed, not how fast they respond. Latency is an operational performance metric that depends on factors like network distance, storage type, and workload patterns, so no fixed 5-millisecond guarantee is included in the storage SLA. While Azure publishes typical latency expectations in some documentation, those are not contractual obligations, and the SLA contains no per-request retrieval time commitment whatsoever.

• ✗

  That Microsoft will pay for all downtime regardless of the cause

  Why it's wrong here

  SLA service credits are only applied when Microsoft itself fails to meet the defined uptime percentage, and they require an incident that is covered by the SLA. Downtime caused by customer configuration errors, insufficient authentication, or out-of-scope network problems is expressly excluded, so Microsoft is not obligated to pay for every outage. Even when a claim is valid, the credit is a discounted percentage of the service fee (typically 10%-25%), not a payment for the full cost of downtime or a penalty that covers all business consequences.