Practice Test #5

아니요. 유료 Azure 서비스의 SLA 보장 가동 시간이 전반적으로 최소 99.9%라는 것은 사실이 아닙니다. SLA는 서비스와 구성에 따라 달라집니다. 일부 서비스는 특정 tier 또는 시나리오에서 99.9% 미만의 SLA를 가질 수 있으며, 일부 서비스는 SLA가 아예 없을 수도 있습니다(특히 preview 기능). 예를 들어, 단일 인스턴스 Virtual Machine은 역사적으로 Availability Set에 배포되거나 Availability Zones에 걸쳐 배포된 VM보다 SLA가 더 낮았습니다. 반대로, 일부 서비스는 중복성 기능과 함께 배포될 때 더 높은 SLA(예: 99.95%, 99.99%)를 제공합니다. 시험에서는 “유료”가 자동으로 “>= 99.9% SLA”를 의미하지 않는다는 점을 이해하기를 기대하며, 해당 SLA를 충족하기 위해서는 특정 서비스의 SLA 문서와 필요한 아키텍처를 확인해야 합니다.

예. 여러 리전에 걸쳐 리소스를 배포하면 단일 리전 장애의 영향을 줄이므로 전체 솔루션 가용성을 높일 수 있으며(더 높은 가용성 목표를 충족하는 데에도 포함될 수 있음) 결과적으로 가동 시간이 향상될 수 있습니다. 실제로는 active-active 또는 active-passive와 같은 multi-region 아키텍처를 사용하고, Azure Traffic Manager, Azure Front Door, 또는 load balancing과 복제된 데이터 저장소(예: geo-redundant 옵션) 같은 서비스를 함께 결합합니다. 각 개별 서비스는 여전히 자체 SLA를 가지지만, 리전 단일 장애 지점을 제거함으로써 복합 애플리케이션의 가동 시간을 개선할 수 있으며, 이는 Azure Well-Architected Framework의 핵심 Reliability 원칙입니다. 핵심 아이디어: multi-region 중복성은 복원력을 향상시키고 단일 리전 배포에 비해 실질적인 end-to-end 가동 시간을 높일 수 있습니다.

아니요. 여러 구독을 구매한다고 해서 SLA에서 보장하는 가동 시간이 증가하지는 않습니다. 구독은 주로 청구, 할당량, 그리고 관리 경계(비용 관리, 액세스 제어 범위 지정, 거버넌스에 사용)입니다. 이는 서비스에 대해 자동으로 중복성, 장애 조치(failover) 기능, 또는 더 높은 가용성 배포 패턴을 생성하지 않습니다. 동일한 단일 인스턴스 워크로드를 두 개의 서로 다른 구독에 배포하더라도, 여전히 같은 리전에 있고 적절한 중복성/장애 조치 설계가 없다면 가용성을 의미 있게 개선한 것이 아닙니다. 가동 시간을 늘리려면 단순히 리소스를 구독 간에 분리하는 것이 아니라, 복원력 있는 아키텍처 요소(여러 인스턴스, Availability Zones, multi-region 배포, 복제된 데이터, 자동화된 장애 조치)를 추가해야 합니다. 구독은 조직적 분리와 한도 관리에는 도움이 될 수 있지만, SLA 개선 메커니즘은 아닙니다.

아니오. 하이브리드 클라우드 모델은 회사가 항상 private cloud 모델에서 마이그레이션해야 한다는 요구사항이 아니다. 하이브리드는 단순히 private 및 public cloud 환경을 결합하는 것을 의미하며, 일반적으로 networking (site-to-site VPN 또는 ExpressRoute), identity (Microsoft Entra ID), 그리고 통합된 management/monitoring과 같은 통합을 포함한다. 회사는 완전히 on-premises(반드시 “private cloud”일 필요는 없음)에서 시작한 뒤, 특정 워크로드(backup, DR, dev/test)를 위해 Azure를 도입하여 하이브리드가 될 수 있다. 또는 회사가 public cloud에서 시작한 후, compliance, data residency, 또는 low-latency 요구를 위해 private cloud/on-premises 리소스를 나중에 추가하는 경우도 있으며, 이 또한 하이브리드이다. 잘못된 “예”는 필수적인 순서(private → hybrid)를 암시하지만, 이는 정의의 일부가 아니다. 시험 관점에서는 정의에 집중하라: hybrid = private와 public의 혼합이며, 필수 마이그레이션 경로가 아니다.

예. 회사는 public cloud를 사용하여 내부 네트워크의 용량을 확장할 수 있습니다. 이는 전형적인 hybrid 사용 사례입니다. 즉, 핵심 시스템은 on-premises에 유지하면서 수요가 급증하거나 추가 하드웨어 구매를 피하고 싶을 때 Azure를 사용해 compute, storage 또는 services 용량을 추가할 수 있습니다. 예로는 cloud bursting(Azure에서 일시적으로 추가 애플리케이션 인스턴스를 실행), backups/archives를 위한 storage 확장, 또는 VPN/ExpressRoute를 통해 on-prem과 연결된 Azure 기반 virtual networks를 추가하여 address space를 확장하고 추가 workloads를 호스팅하는 방식이 있습니다. 이는 Cost Optimization(과도한 사전 프로비저닝 대신 pay-as-you-go), Reliability(추가 용량 및 DR 옵션), 그리고 Scalability/Performance Efficiency(elastic resources)를 지원합니다. AZ-900 관점에서 이 문장은 public cloud 리소스를 on-prem 네트워크와 통합하여 용량을 보강할 수 있으므로 전반적으로 참입니다.

아니요. public cloud 모델에서는 cloud 리소스에 대한 액세스가 회사의 “guest users”로만 제한되지 않습니다. public cloud는 인프라의 소유 및 제공 모델(공급자 소유, multi-tenant)을 의미하며, guest 계정만 리소스에 액세스할 수 있다는 제한을 의미하지 않습니다. 조직의 Azure 리소스에 대한 액세스는 Microsoft Entra ID tenants, Azure RBAC roles, conditional access, network controls와 같은 identity 및 authorization 메커니즘으로 제어됩니다. 사용자는 조직이 허용하는 범위에 따라 내부 직원(member users), 외부 협업자(B2B를 통한 guest users), applications/service principals, managed identities, 자동화된 프로세스 등이 될 수 있습니다. 이 잘못된 문장은 “public cloud” 개념을 “public access”와 혼동하고 있습니다. 리소스는 본질적으로 public에 공개되어 있지 않으며, 명시적으로 노출(예: public endpoints)하고 액세스를 승인하지 않는 한 subscription/tenant에 대해 private입니다.