AZ-900 Describe cloud concepts 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.

• ✗

  SLA and SLO are identical terms for the same concept

  Why it's wrong here

  Although both abbreviations relate to service reliability, they are not synonyms. The SLA is a formal, legally binding agreement between the cloud provider and the customer, defining the minimum level of service and the remedies (typically service credits) if that level is not met. The SLO is an internal, non-contractual objective that an organization sets for itself, often more aggressive than the SLA, to drive operational excellence and catch potential SLA breaches before they occur. Treating them as identical overlooks the fundamental distinction between an external legal commitment and an internal quality goal.

• ✓

  SLA is the provider's contractual guarantee; SLO is an internal organizational goal

  Why this is correct

  In Azure and cloud contracting, an SLA (Service Level Agreement) is a binding contractual guarantee from the provider, such as Microsoft's published uptime commitments (e.g., 99.9% for Virtual Machines), with financial credits if breached. An SLO (Service Level Objective) is an internal organizational target, often set stricter than the SLA (e.g., 99.95%) to provide a safety buffer that ensures the customer never violates their own obligations or user expectations. The SLO is not contractually enforceable by the provider; it is a measure the organization uses for self-monitoring and proactive reliability engineering.

• ✗

  SLO is the provider's contractual guarantee; SLA is the customer's internal target

  Why it's wrong here

  This statement reverses the actual relationship. In cloud computing, the provider (e.g., Microsoft Azure) publishes and contractually commits to an SLA as part of the customer contract, specifying uptime guarantees and credit conditions. The customer or organization, in turn, defines its own SLO as an internal target to ensure its workloads meet or exceed the provider's SLA and internal business requirements. The SLO is not a provider guarantee; it is the customer's internal performance objective, while the SLA is the enforceable contractual promise from the provider. Thus, the described mapping is exactly backwards.

• ✗

  SLA defines performance; SLO defines security requirements

  Why it's wrong here

  This option incorrectly categorizes SLA as performance and SLO as security. In reality, both SLA and SLO are primarily concerned with service reliability and availability—measured as uptime percentages, latency thresholds, or other operational performance metrics—not security. Security commitments are usually covered specifically in separate documents like Azure Trust Center, compliance offerings, or security addenda, not by SLA/SLO definitions. Confusing these terms misstates the purpose of both: SLA is a contractual availability guarantee and SLO is an internal reliability target, neither being a security requirement.