Practice Test #4

예는 오답입니다. 두 region에 VMs가 있다는 사실만으로는 regional failover가 보장되지 않기 때문입니다. Azure Application Gateway는 regional service이므로, 단일 인스턴스는 호스팅 region을 사용할 수 없게 되면 계속해서 traffic을 제공할 수 없습니다. VM 선택은 전체 .NET Framework 및 OS administration 요구 사항을 충족하지만, 아키텍처는 여전히 ingress layer에서 단일 regional dependency를 가지고 있습니다. 올바른 multi-region 설계에는 일반적으로 regional back-end components와 함께 Azure Front Door 또는 Traffic Manager와 같은 global load-balancing service가 필요합니다.

Azure Application Gateway with WAF는 private frontend IP로 배포할 수 있으며 L7 routing 및 WAF 보호를 제공할 수 있습니다. 그러나 API management gateway는 아니며 APIM 스타일의 rate limiting/quota policies를 기본적으로 제공하지 않습니다. 또한 이 시나리오에서 mTLS/client certificate 적용도 일반적인 강점이 아닙니다. private ingress는 부분적으로 충족할 수 있지만 전체 요구 사항 집합은 충족하지 못합니다.

APIM Standard tier는 VNet injection (internal/private gateway)을 지원하지 않습니다. “service endpoint”는 APIM에 VNet 내 private IP address를 제공하는 메커니즘이 아닙니다. 이는 특정 Azure PaaS services에 대한 subnet의 액세스를 보호하는 데 사용됩니다. 따라서 Standard는 mTLS 및 rate limiting을 제공하면서 ingress를 단일 private IP로 제한해야 하는 요구 사항을 충족할 수 없습니다.

Azure Front Door는 anycast public endpoints를 가진 전역 internet-facing 진입점입니다. WAF가 있더라도 VM-to-AKS private communication을 위해 VNet 내부의 단일 private IP로 제한된 ingress를 제공할 수 없습니다. 이는 private VNet 전용 API 노출과 internal consumer에 대한 mTLS를 위한 것이 아니라 public web acceleration 및 global load balancing을 위해 설계되었습니다.

Azure Table Storage는 대용량에 적합한 저비용 key/attribute store이지만, query 기능이 제한적이며 50,000 writes/sec에서의 time-series analytics 또는 near-real-time visualization을 위해 특별히 설계되지 않았습니다. 신중한 partition/row key 설계를 통해 단순 lookups에는 사용할 수 있지만, time windows에 대한 dashboards 및 aggregations는 더 어렵고 일반적으로 추가 analytics services가 필요합니다.

Azure Event Grid는 discrete events를 handlers(Functions, Logic Apps, webhooks)로 전달하는 데 사용되는 event routing 및 notification service(pub/sub)입니다. query를 위한 data를 저장하지 않으며 time-series database도 아닙니다. IoT architecture에서 Event Grid는 events에 반응하는 데 도움이 될 수 있지만, visualization을 위해 telemetry를 저장하고 query해야 한다는 요구 사항은 충족하지 못합니다.

Azure Automation은 script 실행, task scheduling, configuration management 적용을 위한 범용 automation 플랫폼입니다. VM deployment 또는 deployment 후 configuration의 일부를 자동화할 수는 있지만, 기본적인 HPC cluster orchestration이나 third-party scheduler에 대한 내장 인식을 제공하지 않습니다. 또한 cluster template, scheduler 통합 autoscaling, HPC 중심 node lifecycle management와 같은 특화된 기능도 부족합니다. 따라서 Azure HPC cluster를 프로비저닝하고 관리하기 위한 최적의 서비스는 아닙니다.

Azure Purview는 현재 Microsoft Purview의 일부로, data governance, cataloging, classification, compliance에 중점을 둡니다. 그 목적은 조직이 여러 환경에서 data asset을 검색하고 관리하도록 돕는 것이며, compute infrastructure를 배포하거나 운영하는 것이 아닙니다. HPC node provisioning, scheduler integration, cluster resource scaling과는 관련이 없습니다. 따라서 문제에서 설명한 시나리오와는 무관합니다.

Azure Lighthouse는 특히 service provider 또는 여러 Azure tenant를 관리하는 enterprise를 위해 cross-tenant management 및 delegated administration을 목적으로 설계되었습니다. governance, monitoring, operational access를 중앙 집중화하는 데 도움이 되지만, HPC cluster를 배포하거나 관리하지는 않습니다. Lighthouse에는 scheduler integration, compute node provisioning, HPC autoscaling을 위한 내장 기능이 없습니다. 따라서 HPC cluster node를 프로비저닝하고 관리해야 한다는 요구 사항을 충족하지 못합니다.

오답입니다. general-purpose v1(GPv1) storage account는 레거시 account 유형이며 GPv2/Blob account와 같은 유연한 blob tiering 및 가격 모델을 제공하지 않습니다. blob을 저장할 수 있더라도 이 옵션은 Archive tier 사용을 지정하지 않으므로, 검색 지연이 허용되는 드물게 액세스되는 데이터에 대해 요구되는 수준으로 스토리지 비용을 최소화하지 못합니다.

오답입니다. 이 옵션은 GPv2 account에서 Azure Files(file share)를 사용합니다. Azure Files는 SMB/NFS 의미 체계가 필요할 때 적합하지만, Archive tier에 해당하는 기능(offline 스토리지와 rehydration)을 제공하지 않습니다. Cool file share tier는 비용을 줄일 수 있지만, 드물게 액세스되는 데이터에 대해 Blob Archive만큼 줄일 수는 없으므로 Archive와 비교했을 때 “스토리지 비용 최소화” 의도를 충족하지 못합니다.

오답입니다. file share를 사용하는 GPv1은 드물게 액세스되는 데이터의 비용 최소화를 위한 유효하거나 최적의 설계가 아닙니다. Azure Files는 Archive tier를 제공하지 않으며, GPv1은 최신 비용 최적화 및 tiering 기능이 더 적은 레거시입니다. 또한 이 옵션은 rehydration을 통한 24시간 검색 모델을 다루지 않으며, 저비용 offline 스토리지보다는 online file share 액세스를 의미합니다.