Microsoft AZ-900

예는 틀렸습니다. regions는 하나 이상의 datacenters를 포함하는 더 큰 지리적 구성 단위이므로, regions 간 배포는 설명된 것보다 더 넓은 장애 범위를 다룹니다. multi-region design이 전체적인 availability를 향상시킬 수 있는 것은 사실이지만, 단일 datacenter 장애에 대한 요구 사항을 충족하기 위해 일반적으로 사용하는 Azure 기능은 아닙니다. AZ-900 문제에서는 datacenter 수준의 fault tolerance에 대한 기대 정답이 여러 regions가 아니라 Availability Zones입니다.

Dev/Test subscription은 개발 및 테스트 워크로드의 비용을 줄이기 위한 특정 제안(종종 Visual Studio subscriptions을 통해 제공)입니다. Azure Cost Management를 사용하기 위한 전제 조건이 아닙니다. Cost Management는 Dev/Test를 포함한 다양한 subscription 유형의 비용을 분석할 수 있지만, Dev/Test가 있어야 서비스에 접근할 수 있는 것은 아닙니다.

Software Assurance는 Microsoft volume licensing과 연관된 라이선스 혜택(예: Windows Server/SQL Server 혜택, Azure Hybrid Benefit 자격)입니다. 이는 Azure Cost Management에 대한 접근 권한을 부여하지 않습니다. Cost Management는 Software Assurance entitlement가 아니라 Azure billing 및 scopes(billing account/subscription)에 연결됩니다.

Enterprise Agreement (EA)는 대규모 조직을 위한 구매 계약이며, Azure Cost Management를 사용하기 위해 필요하지 않습니다. EA 고객이 대규모로 Cost Management를 사용하는 경우가 흔하고(종종 고급 chargeback/showback 요구), 비EA 고객도 해당 도구를 사용할 수 있습니다. EA는 구매 모델이지 기능적 전제 조건이 아닙니다.

SaaS는 공급자가 관리하는 완전한 즉시 사용 가능한 애플리케이션(예: Microsoft 365)을 제공합니다. 관리 부담을 가장 많이 줄여주지만, 일반적으로 사용자 지정 웹 애플리케이션 코드를 그대로 배포할 수는 없으며, 사용자의 애플리케이션을 호스팅하는 대신 공급업체의 애플리케이션을 채택하는 형태가 됩니다. 기존 사용자 지정 웹 앱을 마이그레이션하는 경우, 앱을 완전히 대체하는 상황이 아니라면 SaaS는 보통 적합하지 않습니다.

IaaS(virtual machines)는 가장 많은 제어를 제공하며 lift-and-shift 마이그레이션에 흔히 사용되지만, 가장 많은 관리가 필요합니다. OS, 패치, 웹 서버/런타임 구성, 스케일링 설정, 백업, 그리고 지속적인 유지 관리를 사용자가 책임져야 합니다. 요구 사항이 관리 노력 최소화이므로, IaaS는 주요 서비스 모델 중 일반적으로 가장 부적합한 선택입니다.

DaaS(Database as a Service)는 공급자가 데이터베이스 인프라와 많은 유지 관리 작업을 관리하는 관리형 데이터베이스 제공 서비스(예: Azure SQL Database, Azure Cosmos DB)를 의미합니다. DaaS는 데이터베이스 관리 부담을 줄일 수 있지만, 웹 애플리케이션 자체를 호스팅하는 문제를 해결하지는 않습니다. 웹 계층을 위해서는 여전히 PaaS 또는 IaaS와 같은 compute/hosting 모델이 필요합니다.

오답입니다. 캐나다 정부 계약업체는 자동으로 Azure Government를 사용할 자격이 있지 않습니다. Azure Government는 미국 정부 기관과 승인된 미국 정부 계약업체를 위한 미국 sovereign cloud입니다. 캐나다 공공 부문 조직은 일반적으로 캐나다의 상용 Azure 리전(또는 다른 방식)을 사용하지만, 정부 계약업체라는 이유만으로 Azure Government 자격을 얻지는 못합니다.

오답입니다. 유럽 정부 계약업체는 기본적으로 Azure Government를 사용할 자격이 없습니다. Azure Government는 미국 정부 기관과 검증된 미국 정부 계약업체로 제한됩니다. 유럽 계약업체는 유럽의 상용 Azure 리전 또는 다른 sovereign solutions를 사용할 수 있지만, 특정 미국 적격성 요건을 충족하지 않는 한(이 선택지는 이를 시사하지 않음) Azure Government를 사용할 수 없습니다.

오답입니다. 유럽 정부 기관은 Azure Government를 사용할 자격이 없습니다. 이 서비스는 미국 공공 부문 고객과 승인된 계약업체만 제한적으로 접근할 수 있는 미국 sovereign cloud 환경입니다. 유럽 정부 기관은 일반적으로 유럽 리전의 상용 Azure 또는 다른 sovereign offerings를 사용하지만 Azure Government는 아닙니다.

Azure CLI는 App Service를 포함한 Azure 리소스를 관리하기 위한 command-line 도구입니다. 그러나 일반적으로 로컬 설치와 지원되는 OS/shell 환경이 필요합니다. iPhone은 Azure CLI를 네이티브로 설치하고 실행하는 표준 플랫폼이 아니므로, 시험 문맥에서 휴대폰에서 직접 web app 설정을 관리하기 위한 완전한 솔루션으로 간주되지 않습니다.

Windows PowerShell은 Azure를 관리하는 데 흔히 사용되는 scripting 및 automation 환경(대개 Az PowerShell module 사용)입니다. 그러나 Windows(또는 최소한 호환되는 PowerShell runtime) 환경을 전제로 합니다. iPhone은 표준 Windows PowerShell 실행 환경을 네이티브로 제공하지 않으므로, 휴대폰에서 설정을 관리하기 위한 완전한 솔루션이 아닙니다.

Azure Storage Explorer는 Azure Storage 리소스(blobs, files, queues, tables)를 관리하도록 설계된 클라이언트 애플리케이션입니다. App Service web app 설정을 구성하거나 관리하기 위한 용도가 아닙니다. 또한 모바일 우선 관리 옵션이 아니라 데스크톱 도구이므로 이 요구 사항에 적합하지 않습니다.

Elasticity는 수요에 맞춰 리소스를 자동으로 추가하거나 제거하는 것을 의미합니다(예: 피크 사용량 동안 autoscaling으로 확장하고 수요가 감소하면 축소). Elasticity는 가변 부하에서 비용 효율성과 성능을 개선하지만, fault-tolerant한 multi-zone 또는 multi-region 설계와 결합되지 않는 한 데이터 센터 장애로부터 본질적으로 보호해 주지는 않습니다.

Scalability는 수직적(더 큰 VM) 또는 수평적(더 많은 인스턴스)으로 용량을 늘려 성장을 처리하는 능력입니다. Elasticity와 마찬가지로 scalability는 용량과 성능에 초점을 맞추며 복원력과는 다릅니다. 모든 인스턴스가 단일 데이터 센터에 있고 그 데이터 센터를 사용할 수 없게 되면, 확장 가능한 시스템이라도 중단될 수 있습니다.

Low latency는 네트워크 지연을 최소화하여 사용자가 더 빠른 응답을 받도록 하는 것을 의미하며, 보통 더 가까운 리전을 선택하거나 CDN을 사용하거나 라우팅을 최적화하여 달성합니다. Latency는 성능 특성이지 가용성 전략이 아닙니다. 데이터 센터 또는 zone 전반의 redundancy가 없다면, low-latency 배포도 다운타임을 겪을 수 있습니다.

전용 하드웨어는 퍼블릭 클라우드의 표준 특성이 아닙니다. 퍼블릭 클라우드는 일반적으로 논리적 격리(멀티 테넌시)를 갖춘 공유 물리 인프라를 사용합니다. Azure는 규정 준수 또는 라이선스 요구를 위해 전용 옵션(예: Azure Dedicated Host, isolated SKUs)을 제공하지만, 이는 퍼블릭 클라우드를 정의하는 모델이라기보다 특수 서비스입니다.

보안되지 않은 연결은 퍼블릭 클라우드의 특성이 아닙니다. 퍼블릭 클라우드 서비스는 강력한 identity(Microsoft Entra ID), 전송/저장 시 암호화, 네트워크 제어(NSGs, firewalls), private connectivity 옵션(VPN/ExpressRoute, Private Link)을 통해 보안이 설계됩니다. 보안은 공유 책임이며 퍼블릭 클라우드의 고유한 약점이 아닙니다.

제한된 스토리지는 일반적인 퍼블릭 클라우드 특성과 반대입니다. 퍼블릭 클라우드 플랫폼은 온디맨드로 확장 가능한 스토리지(예: Azure Blob Storage, managed disks, Azure Files)를 다양한 성능 및 중복성 티어로 제공합니다. quota와 service limits가 존재하긴 하지만, 모델은 본질적으로 제한적이라기보다 탄력적이고 확장 가능합니다.

고가용성은 중복(여러 인스턴스, zones, regions)과 장애 조치(failover)를 사용해 장애가 발생하더라도 애플리케이션이 계속 실행되도록 하는 것입니다. 이는 복원력을 개선하고 가동 시간 SLAs를 지원하지만, 추가 용량을 실행하므로 일반적으로 비용이 증가합니다. 낮은 수요 기간에 리소스를 줄여야 하는 요구를 구체적으로 해결하지 않으므로, 이 사용 패턴에 대한 최적의 비용 관리 이점이 아닙니다.

높은 지연 시간은 사용자와 애플리케이션 간 응답 시간이 느려지는 것을 의미하며, 보통 거리, 네트워크 혼잡 또는 비효율적인 아키텍처로 인해 발생합니다. 이는 클라우드 서비스의 이점이 아니며 비용 관리를 지원하지도 않습니다. 시험 관점에서 지연 시간은 사용자와 가까운 regions, CDNs, 캐싱, 최적화된 네트워킹을 사용해 최소화하려는 대상이지, 장점으로 선택하는 항목이 아닙니다.

부하 분산은 들어오는 트래픽을 여러 인스턴스에 분산하여 성능과 안정성을 향상시킵니다. 높은 트래픽을 처리하는 데 도움이 되지만, 부하 분산기 뒤의 인스턴스를 여전히 프로비저닝(또는 확장)해야 하므로 본질적으로 비용을 줄이지는 않습니다. 부하 분산은 종종 탄력성(autoscaling + load balancing)과 함께 사용되지만, 단독으로는 사용량이 낮을 때 스케일 다운하는 문제를 해결하지 못합니다.

public cloud로의 완전한 마이그레이션은 온-프레미스 하드웨어 구매를 없애 CapEx를 줄일 수 있고, managed services를 통해 일부 OpEx를 낮출 수도 있습니다. 그러나 조직이 이미 상당한 온-프레미스 투자를 보유하고 있고 추가 용량만 필요하다면 “완전한 마이그레이션”이 항상 비용을 가장 최소화하는 권장 사항은 아닙니다. 또한 마이그레이션 프로젝트는 전환 비용, 시간, 그리고 잠재적 리팩터링을 수반합니다.

추가 data center는 CapEx와 OpEx를 모두 증가시킵니다. 토지/공간, 서버, 네트워킹, 스토리지를 구매해야 하며, 전력, 냉각, 물리 보안, 유지보수, 인력에 대한 지속 비용을 지불해야 합니다. 이는 자본 및 운영 지출을 최소화해야 한다는 요구 사항과 정면으로 충돌하며, cloud의 탄력성 이점도 제공하지 못합니다.

private cloud는 cloud와 유사한 관리 및 가상화를 제공하지만, 여전히 조직이 소유하고 운영(또는 전용 호스팅)합니다. 일반적으로 하드웨어에 대한 상당한 초기 투자와 지속적인 운영 관리가 필요하므로, 필요 시 public cloud 리소스를 사용하는 것에 비해 CapEx/OpEx를 최소화하지 못합니다. 또한 동일한 수준의 탄력성과 pay-as-you-go 경제성을 제공하지 못합니다.

Premier support는 architectural guidance와 광범위한 proactive services를 제공할 수 있으므로 technical requirement는 충족할 수 있습니다. 그러나 이는 폭넓고 지속적인 support management와 proactive engagement가 필요한 조직을 위한 상위 enterprise support offering입니다. 문제는 구체적으로 비용 최소화를 요구하므로, Premier는 필요 이상으로 비쌉니다. Professional Direct는 더 낮은 비용으로 필요한 architectural advisory capability를 제공합니다.

Developer support는 enterprise architectural review 요구보다는 trial, development, non-production use cases를 위한 것입니다. 지원 범위가 제한적이며, 공식적인 architectural review 요청이 암시하는 advisory architecture services를 포함하지 않습니다. 더 저렴하더라도 요구 사항을 충족하지 못합니다. 비용 최소화는 기능적 요구 사항이 충족된 이후에만 적용됩니다.

Standard support는 production workloads에 대한 technical support를 제공하며, 특정 severity에 대해 더 빠른 response와 24/7 access를 포함하지만, 주로 reactive support plan입니다. Professional Direct와 관련된 advisory 또는 architecture review services는 포함하지 않습니다. 문제는 구체적으로 Microsoft에 architectural review를 요청하는 것에 관한 것이며, 이는 standard technical support 이상의 것을 요구합니다. 따라서 Standard는 비용이 더 낮더라도 충분하지 않습니다.

"예"라고 답하는 것은 잘못입니다. DDoS Protection은 HTTP 트래픽이 VM에 도달하도록 허용되는지 여부를 제어하지 않습니다. DDoS Standard가 활성화되어 있더라도 VM1에 public IP(또는 public load balancer/app gateway front end)가 없거나 NSG가 TCP/80을 차단하면 Internet에서의 HTTP 액세스는 실패합니다. DDoS protection은 이미 public인 리소스에 대한 추가 보안이며, 서비스를 게시하거나 포트를 열지 않습니다. VM1을 HTTP로 노출하려면 여전히 명시적인 네트워킹 구성이 필요합니다.

“변경할 필요 없음”은 Resource groups가 여러 구독에 걸친 규정 준수 관리를 제공하지 않기 때문에 틀립니다. Resource group은 단일 구독 범위로 제한되며 주로 리소스를 구성하고, 해당 범위에서 RBAC를 적용하고, 배포 및 삭제 같은 수명 주기 작업을 관리하기 위한 것입니다. Resource group 수준에서 태그를 지정하고 액세스를 제어할 수는 있지만, 이는 규정 준수 규칙을 정의하고 강제하는 것과는 다릅니다. 구독 간 규정 준수에는 적절한 범위에 적용된 Azure Policy 같은 거버넌스 서비스가 필요합니다.

Management groups는 구독을 계층 구조로 구성하고 여러 구독에 걸쳐 Azure Policy 및 RBAC 같은 거버넌스 제어를 적용하기 위한 범위를 제공합니다. 그러나 Management groups 자체가 규정 준수 규칙을 정의하거나 강제하지는 않으며, 컨테이너/범위 역할을 합니다. 실제로 규정 준수를 관리하려면 Management group 범위에 Azure Policy(또는 initiatives)를 할당해야 합니다. 따라서 텍스트를 “Management groups”로 바꾸는 것은 불완전하며 규정 준수 강제 측면에서 기술적으로 부정확합니다.

Azure App Service plans는 웹 앱, API, functions를 호스팅하기 위한 컴퓨팅 및 가격 책정 구성 요소로, 지역, SKU, 확장 특성을 정의합니다. 이는 거버넌스, 규정 준수 평가 또는 리소스/구독 전반에서 구성 표준을 강제하는 것과는 관련이 없습니다. App Service plans는 App Service 워크로드에만 적용되며 정책 기반 규정 준수 제어를 제공하지 않습니다. 이 시나리오는 규정 준수 관리에 관한 것이며, 이는 호스팅 플랜이 아니라 Azure Policy로 해결합니다.

Load Balancer는 여러 VMs에 걸쳐 네트워크 트래픽(Layer 4)을 분산하여 가용성과 확장성을 향상시킵니다(인바운드 또는 내부 트래픽). 이는 온-프레미스에서 Azure로의 프라이빗 연결을 생성하지 않으며, 트래픽이 이미 Azure에 있거나(또는 인터넷/VNet에서 들어오는 경우) 그 이후에만 분산합니다. 따라서 온-프레미스 클라이언트 통신을 Azure VMs로 가능하게 하는 데 필요한 리소스가 아닙니다.

Application Gateway는 SSL 종료, 경로 기반 라우팅, WAF 같은 기능을 제공하는 Layer 7(HTTP/HTTPS) load balancer입니다. 이는 웹 애플리케이션을 게시하고 보호하는 데 사용되며, 하이브리드 네트워크 연결을 설정하기 위한 것이 아닙니다. 온-프레미스 사용자에게 웹 앱을 노출하려는 경우에도, 프라이빗 네트워크 통신을 위한 VPN/ExpressRoute gateway의 필요성을 대체하지는 못합니다.

virtual network는 Azure VMs가 위치하는 private IP 주소 공간과 subnets를 제공합니다. VNet은 VMs를 호스팅하기 위한 기반이지만, 문제는 온-프레미스 클라이언트가 해당 VMs와 통신할 수 있도록 하는 데 초점을 둡니다. 선택지 중 구체적인 하이브리드 연결 요구 사항은 Virtual Network Gateway와 GatewaySubnet이며, 환경에 이미 VMs가 포함되어 있으므로 VNet은 이미 존재한다고 가정합니다.

"예"라고 답하는 것은 Azure Firewall이 VM1을 HTTP로 노출하는 데 필요하고 충분한 제어라고 가정합니다. 그러나 Azure Firewall은 Internet-to-VM 트래픽의 인바운드 경로에 자동으로 포함되지 않으며, 명시적인 DNAT 구성과 라우팅 없이는 서비스를 게시하지 않습니다. 이러한 특정 구성(그리고 일반적으로 이에 대응하는 NSG 허용) 없이는 firewall을 수정하더라도 VM1을 Internet에서 TCP/80으로 액세스 가능하게 만들지 못합니다.