Practice Test #1

Azure Advisor는 비용, 보안, 안정성, 운영 우수성 및 성능 전반에 걸친 모범 사례 권장 사항에 중점을 둡니다. ARM deployment의 권한 있는 감사 추적이나 새로운 deployment의 전체 목록을 제공하지 않습니다. Advisor는 deployment로 인해 발생한 구성 문제를 강조할 수는 있지만, 규정 준수 스타일의 deployment 보고용으로 설계된 것은 아닙니다.

Azure Analysis Services는 Power BI와 같은 BI 도구에서 사용하는 tabular semantic model(SSAS Tabular와 유사)을 호스팅하기 위한 PaaS analytics 서비스입니다. 자체적으로 Azure subscription Activity Log 이벤트를 수집하거나 추적하지 않습니다. 이론적으로는 다른 곳으로 로그를 export한 후 데이터를 모델링할 수 있지만, deployment 보고서를 생성하기 위한 올바른 기본 서비스는 아닙니다.

Azure Monitor action groups는 alert rule에서 사용하는 알림 및 자동화 endpoint(email, SMS, webhook, Logic Apps 등)를 정의합니다. ARM deployment 이벤트를 수집, 저장 또는 나열하지 않습니다. Activity Log/Log Analytics에 대한 alert를 만든 후 action groups를 사용할 수는 있지만, 월간 deployment 보고서의 데이터 소스는 아닙니다.

이 옵션은 제안된 솔루션이 제시된 목표를 충족하기 때문에 오답입니다. IP flow verify는 유효한 NSG 규칙을 기반으로 traffic이 허용되는지 또는 차단되는지를 확인하는 핵심 Azure Network Watcher 진단 기능 중 하나입니다. 비록 전체 packet inspection을 수행하거나 ExpressRoute 전반의 모든 hop을 추적하지는 않지만, 문제는 virtual machine에 대한 packet이 허용되는지 또는 거부되는지를 식별하는 것만 요구합니다. 그 목적에는 IP flow verify가 적절하고 충분한 도구입니다.

active geo-replication을 사용하는 Azure SQL Database는 DR 및 read scaling을 위해 다른 regions에 readable secondary replicas를 제공하지만, multi-master writes는 지원하지 않습니다. writes를 수락하는 것은 primary database뿐이며 secondaries는 read-only입니다. 사용자가 가까운 secondary에서 읽는다면 낮은 지연 시간의 reads 요구 사항은 충족할 수 있지만, multi-master write 요구 사항은 충족하지 못합니다.

Azure SQL Database Hyperscale은 매우 큰 databases와 빠른 scale에 최적화된 tier로, compute와 storage를 분리하는 architecture를 가지며 read replicas를 사용할 수 있습니다. 그러나 여전히 single-writer model을 따르며 regions 간 multi-master writes를 제공하지 않습니다. read performance 및 scale에는 도움이 될 수 있지만, multi-master 요구 사항은 충족하지 못합니다.

Azure Database for PostgreSQL은 표준 SQL을 지원하고 reads 확장을 위한 read replicas를 제공할 수 있지만, managed service는 기본 제공 기능으로 native multi-master, multi-region writes를 제공하지 않습니다. 일반적인 HA/DR 패턴은 replicas가 있는 single primary입니다. multi-master를 구현하려면 복잡한 custom replication/conflict handling이 필요하며, 이는 의도된 managed solution이 아닙니다.

Azure Notification Hubs는 mobile devices(iOS/Android) 및 browsers에 messages를 보내기 위한 push notification service입니다. 이는 사용자에게 fan-out notifications를 보내는 데 최적화되어 있으며, 안정적인 service-to-service transactional messaging용이 아닙니다. order/billing/payment workflow integration에 필요한 dead-lettering, sessions, enterprise delivery semantics를 갖춘 queues/topics 같은 핵심 broker 기능이 부족합니다.

Azure Data Lake (Azure Data Lake Storage Gen2)는 big data analytics storage(Hadoop/Spark)를 위해 설계되었으며, batch 및 analytical workloads를 위한 대량의 structured/unstructured data를 저장합니다. XML files를 저장할 수는 있지만 messaging system이 아니며, microservices를 위한 message locks, retries, subscriptions, guaranteed delivery patterns와 같은 비동기 broker 기능을 제공하지 않습니다.

Azure Blob Storage는 unstructured data(files, documents, logs)를 위한 object storage입니다. XML documents를 저장하고 services가 변경 사항을 polling하도록 할 수는 있지만, 이는 비효율적이며 messaging guarantees, consumer coordination, built-in retry/dead-letter patterns가 부족합니다. Blob Storage는 transactional workflows를 위한 message broker로 의도된 것이 아니라 주로 storage용이며, 비동기 integration용이 아닙니다.

Azure SQL Database Serverless는 General Purpose 내의 compute tier로, auto-scale 및 auto-pause를 통해 간헐적 사용의 비용을 줄입니다. 이는 replica 간 데이터 손실 없는 failover를 보장하도록 설계되지 않았으며, zone 복원력을 갖춘 synchronous replica를 본질적으로 제공하지도 않습니다. 이는 가변적 workload에 대한 비용 최적화를 다루며, RPO=0 및 zone-outage survivability와 같은 엄격한 HA 요구 사항을 위한 것이 아닙니다.

Azure SQL Database Basic은 작고 요구 사항이 낮은 workload를 위한 것이며, 데이터 손실 없는 failover에 필요한 multi-replica synchronous 아키텍처를 제공하지 않습니다. 또한 zone outage 동안에도 계속 사용 가능해야 하는 고급 HA/zone redundancy 기능도 지원하지 않습니다. 비용은 최소화하지만 reliability 요구 사항을 충족하지 못합니다.

Azure SQL Database Standard는 일반적인 workload를 위한 하위 service tier이며, Business Critical과 같은 synchronous multi-replica 고가용성 아키텍처를 제공하지 않습니다. 따라서 요구 사항이 데이터 손실 없는 replica 간 failover를 명시적으로 요구하는 경우 올바른 선택이 아닙니다. 또한 mission-critical database workload에 기대되는 수준의 zone-resilient availability도 제공하지 않습니다. 비용은 더 저렴하지만, 명시된 복원력 요구 사항을 충족하지 못합니다.

Azure App Service web app은 유지 관리를 최소화하는 관리형 PaaS 제품이지만, 고객 애플리케이션에 Windows Application event log에 대한 직접 액세스를 제공하지 않습니다. App Service는 임시 로컬 스토리지를 제공하지만, 이는 두 가지 기술 요구 사항 중 하나만 충족합니다. event log 쓰기를 App Service diagnostics 또는 Application Insights로 대체하려면 애플리케이션 동작을 변경해야 하며, 문제에서는 이를 허용하지 않습니다. 따라서 App Service는 더 저렴하고 관리가 더 쉽더라도 명시된 요구 사항을 완전히 충족할 수 없습니다.

App Service Environment는 여전히 Azure App Service 기반이므로 Windows Application event log에 대한 직접 액세스와 관련해 동일한 플랫폼 제한이 있습니다. 이는 격리, 네트워킹 제어 및 전용 용량을 제공하지만, Event Viewer에 쓰기 위한 guest OS 수준 제어는 제공하지 않습니다. 또한 ASE는 다른 선택지보다 훨씬 더 비싸며 비용을 최소화해야 한다는 요구 사항과 직접적으로 충돌합니다. 기술적 적합성과 비용 목표를 모두 충족하지 못하므로 올바른 권장 사항이 아닙니다.

Azure Functions app은 Windows OS 기능에 의존하는 기존 web service를 호스팅하기 위한 것이 아니라 event-driven 실행 패턴을 위한 serverless 컴퓨팅 옵션입니다. Functions는 제한적인 방식으로 임시 로컬 스토리지를 사용할 수 있지만, 애플리케이션 쓰기를 위해 Windows Application event log를 노출하지는 않습니다. App Service와 마찬가지로 대신 Application Insights를 사용하는 것은 명시적 요구 사항을 충족하는 것이 아니라 재설계에 해당합니다. 따라서 Functions는 적절한 워크로드에 대해 운영 오버헤드와 비용을 줄일 수 있더라도 요구 사항을 충족하지 못합니다.

Azure의 role-based access control (RBAC)은 management plane을 통해 Azure 리소스(subscription, resource group, SQL server resource)에 대한 access를 제어합니다. 이것만으로는 사용자가 Azure SQL Database 내부에서 어떤 데이터를 쿼리할 수 있는지를 제한하지 않습니다. data-plane 권한은 Azure RBAC만이 아니라 SQL login/user, database role, 그리고 DDM/RLS와 같은 기능으로 처리됩니다.

Data Discovery & Classification은 Azure SQL에서 민감한 데이터 column(예: PII)을 검색, 레이블 지정, 추적하는 데 도움을 줍니다. 이는 거버넌스, 보고, 그리고 권장 사항 유도(예: Microsoft Defender for SQL에서)를 지원하지만, 권한이 있는 사용자만 데이터를 볼 수 있도록 강제하지는 않습니다. 이는 access control 메커니즘이 아니라 보완적인 거버넌스 기능입니다.

Transparent Data Encryption (TDE)은 database, log, backup을 저장 시점에 암호화하여 파일이나 backup에 대한 오프라인 access로부터 보호합니다. 그러나 database를 쿼리할 수 있는 사용자가 결과에서 PII를 보는 것을 막지는 않습니다. TDE는 저장 중 암호화 요구 사항을 해결하며, 권한 있는 사용자와 비권한 사용자의 선택적 가시성을 해결하지는 않습니다.