Microsoft AZ-204

'예'라고 답하는 것은 잘못되었습니다. 제안된 아키텍처는 핵심 요구 사항을 충족하지 못합니다. Storage Queues는 FIFO 순서를 안정적으로 보장할 수 없으므로 메시지 처리 순서가 유지되지 않을 수 있습니다. VM은 polling worker를 구현하거나 event-driven compute 서비스를 추가하지 않는 한 Storage Queue 이벤트에 의해 직접 트리거되지 않으며, 이 솔루션은 queue가 80 GB를 초과하여 증가하는 것을 방지하기 위한 제어(throttling, TTL 또는 quotas 등)도 구현하지 않습니다.

Event Hubs는 고처리량 event streaming(telemetry ingestion)에 최적화되어 있으며 partitions와 consumer groups를 사용합니다. 여러 consumer groups가 동일한 stream을 읽을 수는 있지만, business messaging에 사용되는 전형적인 pub-sub broker 패턴은 아니며, 소비는 일반적으로 partition에서 pull 기반으로 읽는 방식입니다. push 기반 pub-sub notifications보다는 streaming pipeline(Stream Analytics, Spark)에 가장 적합합니다.

Queue(Azure Storage Queues 등)는 competing consumers를 사용하는 point-to-point messaging을 구현합니다. 각 message는 일반적으로 단일 consumer에 의해 처리됩니다. 기본적인 publish-subscribe fan-out 모델을 제공하지 않습니다. Queue는 triggers와 함께 사용할 때 강한 결합을 줄이고 polling을 줄일 수는 있지만, 여러 subscriber가 동일한 message를 수신하는 pub-sub 요구 사항은 충족하지 않습니다.

'예'라고 답하는 것은 Event Grid가 디바이스 telemetry 수집을 직접 수신하고 관리할 수 있다고 가정하기 때문에 잘못되었습니다. Event Grid는 이벤트를 필터링하고 라우팅할 수 있지만, 디바이스 수집 게이트웨이가 아니며 전 세계에 분산된 수천 개의 디바이스에 일반적으로 필요한 연결, authentication, 수집 의미 체계를 제공하지 않습니다. 또한 디바이스 식별자에 대한 filtering은 라우팅만 결정할 뿐이며, 내구성 있는 수집 및 상관관계/저장소 구성을 본질적으로 제공하지 않습니다. IoT Hub 또는 Event Hubs가 이러한 유형의 워크로드를 위해 의도된 서비스이며, 이후 Blob storage에 저장됩니다.

Azure Event Hubs는 고처리량 event streaming 및 telemetry 수집(예: IoT, 로그)에 최적화되어 있습니다. 이는 구성된 시간 범위 동안 event를 보존하며, 개별 작업을 처리하는 competing workers가 아니라 partitions/consumer groups를 통해 소비됩니다. “나중에 처리하기 위해 완료된 계약 저장”에는 streaming analytics pipeline을 구축하는 경우가 아니라면 일반적으로 잘못된 추상화입니다.

Azure Service Bus topic은 여러 subscription과 고급 messaging 기능(sessions, transactions, dead-lettering, duplicate detection)을 지원하는 publish/subscribe를 제공합니다. 여러 독립 시스템이 반응해야 하는 경우 계약 완료 event에 사용할 수 있습니다. 그러나 단순히 나중에 처리하기 위한 완료된 계약 작업 항목을 저장하는 목적이라면, 일반적으로 Storage queues에 비해 더 복잡하고 비용도 더 듭니다.

Azure Event Grid topic은 push delivery 및 event filtering을 사용하여 event 알림을 handler(Functions, WebHooks, Service Bus 등)로 라우팅하기 위한 것입니다. 완료된 계약을 저장하는 메커니즘이나 작업 queue로 설계된 것이 아닙니다. Event Grid는 “계약 완료”를 여러 subscriber에게 브로드캐스트해야 할 때 적절하지만, 여전히 계약 자체는 다른 곳에 저장하고/또는 작업을 enqueue해야 합니다.

아니요는 틀렸습니다. Blob storage events는 blob이 생성되거나 업데이트될 때 후속 서비스를 빠르게 알리도록 특별히 설계되었습니다. 요구 사항은 전체 이미지 변환이 그 시간 내에 완료되어야 한다는 것이 아니라, 프로세스가 1분 이내에 시작되어야 한다는 것입니다. polling 또는 scheduled 방식은 이 요구 사항을 충족하지 못할 수 있지만, Blob storage의 event-based trigger는 이를 충족합니다.

'예'라고 답하는 것은 잘못되었습니다. 이는 Service Bus를 디바이스 telemetry 수집 서비스로 과대평가하기 때문입니다. correlation filter는 메시지를 subscription으로 라우팅하는 데 도움이 될 수 있지만, 안전한 디바이스별 연결, throttling 패턴, IoT 프로토콜 지원과 같은 디바이스 규모 수집 요구 사항을 본질적으로 해결하지는 못합니다. 또한 전 세계의 많은 매장과 향후 성장을 강조하는 이 시나리오는 고 fan-in 이벤트 수집과 Blob storage로의 손쉬운 저장(routing 또는 Capture를 통해)을 위해 설계된 IoT Hub 또는 Event Hubs와 더 잘 부합합니다. 따라서 제안된 Service Bus topic 접근 방식은 의도된 목표를 완전히 충족하지 못합니다.

'예'라고 답하는 것은 Notification Hubs가 device telemetry를 수신하고 저장할 수 있음을 의미하지만, 이 서비스의 주된 기능은 inbound 데이터 수집이 아니라 outbound push notification 전송입니다. Notification Hubs의 device registration은 telemetry 수집을 위한 device authentication이나 수신 데이터를 device ID로 상호 연관하기 위한 것이 아니라 notification 대상 지정(tags/templates)을 위한 것입니다. 또한 수신 device 데이터를 Azure Blob Storage에 직접 기록하는 통합 기능도 제공하지 않습니다. 따라서 설명된 수집 및 저장 요구 사항을 충족하지 못합니다.

"예"라고 답하는 것은 잘못되었습니다. storage account 유형을 변환해도 event-driven pipeline이 생성되지 않으며 처리가 1분 이내에 시작된다고 보장하지도 않습니다. Premium BlockBlobStorage는 blob 읽기/쓰기 성능을 향상시킬 수 있지만, 업로드를 감지하고 처리 로직을 호출하는 메커니즘을 제공하지는 않습니다. 누락된 구성 요소는 event/trigger service(예: Event Grid)와 처리를 시작할 compute 대상(예: Azure Functions)입니다. 따라서 이 변경만으로는 처리를 빠르게 시작한다는 목표를 충족할 수 없습니다.

아니요는 이 시험의 맥락에서 제안된 설계가 명시된 목표를 충족하므로 틀렸습니다. 요구 사항은 업로드 직후 처리를 시작하는 것이며, Blob-triggered Azure Functions는 바로 그런 종류의 storage 기반 자동화를 위해 특별히 의도되었습니다. 실제 환경에서는 약간의 trigger 지연이 있을 수 있지만, 이 솔루션은 여전히 1분 이내 시작에 유효한 것으로 간주됩니다. 따라서 이 솔루션을 거부하는 것은 예상되는 Azure 설계 패턴과 일치하지 않습니다.

Event Grid + Azure Functions는 비동기 처리 및 blob events에 대한 near-real-time 반응에 적합합니다. 그러나 compliance를 위한 권위 있는 transaction log는 아닙니다. 전달은 at-least-once이며, events가 중복될 수 있고, 모든 events에 대해 순서가 보장되지 않습니다. 보존도 본질적으로 제공되지 않으므로 events를 직접 저장해야 하며, 잘못 구성하면 여전히 events를 놓칠 수 있습니다.

Storage Analytics logging(classic)은 request 수준의 logs를 캡처하지만, legacy 접근 방식이며 특히 blob 및 metadata 변경 사항에 대한 순서 있는 간결한 change log 요구 사항에 최적화되어 있지 않습니다. 많은 작업 유형으로 인해 noisy할 수 있고, parsing이 필요하며, Blob Change Feed 및 Azure Monitor diagnostic settings와 비교할 때 change tracking/auditing을 위한 권장되는 최신 솔루션이 아닙니다.

Azure Monitor HTTP Data Collector API는 custom logs를 Log Analytics로 보내는 데 사용됩니다. 이는 storage transaction history에 대한 기본 액세스를 제공하지 않습니다. 여전히 blob operations에 대한 source of truth가 필요하며, request bodies를 스캔하는 것은 blobs 및 metadata에 대한 순서 있는 create/update/delete/copy 변경 사항을 재구성하는 지원되거나 신뢰할 수 있는 방법이 아닙니다.

Azure AD Application Proxy는 on-premises web applications를 Azure AD를 통해 외부 사용자에게 안전하게 게시하는 데 사용됩니다(pre-authentication, conditional access). 이는 사용자-앱 원격 액세스 솔루션이지, Logic Apps connectors가 on-premises databases 또는 내부 시스템에 도달하기 위한 통합 메커니즘이 아닙니다. 일반적으로 Logic Apps가 managed connectors를 통해 SQL Server 또는 file shares와 같은 on-prem 리소스에 액세스할 수 있게 하지는 않습니다.

Site-to-Site VPN은 on-premises network를 Azure VNet에 연결하여 많은 리소스에 대해 private IP connectivity를 가능하게 합니다. 그러나 표준 Logic Apps(Consumption)는 일반적으로 on-prem endpoints로 VPN을 통해 직접 라우팅하기보다 connector 패턴에 의존합니다. 시나리오에서 VNet-integrated Logic Apps/ISE 및 private routing 요구 사항을 명시적으로 언급하지 않는 한, S2S VPN은 일반적으로 connector 기반 on-prem 액세스에 대해 기대되는 정답이 아닙니다.

Point-to-Site VPN은 개별 client devices가 Azure VNet에 연결하도록 설계되었습니다(원격 사용자 액세스). 이는 on-premises datacenter에 대한 지속적이고 확장 가능한 connectivity를 제공하거나 Logic Apps와 같은 server-side services가 on-prem 리소스에 도달하도록 하기 위한 것이 아닙니다. 조직 전체의 hybrid connectivity에는 P2S가 아니라 S2S VPN 또는 ExpressRoute를 사용합니다.

Azure App Service Environment (ASE)는 VNet 내부에서 Azure App Service 리소스(Web Apps, API Apps, 일부 Function App 시나리오)를 호스팅하기 위한 격리되고 전용된 environment를 제공합니다. 그러나 Azure Logic Apps를 보안하거나 호스팅하는 표준 메커니즘은 아닙니다. ASE를 선택하는 것은 응시자가 “보안 호스팅”을 “ASE”와 동일시할 때 흔히 하는 실수이지만, Logic Apps는 VNet 삽입을 위해 ISE를 사용합니다.

VNet service endpoint는 VNet의 identity를 지원되는 Azure PaaS 서비스(Azure Storage 또는 Azure SQL 등)로 확장하여 traffic이 Azure backbone에 머물도록 하고 해당 VNet으로 액세스를 제한할 수 있게 합니다. 그러나 Logic App endpoint 자체를 보안하거나 Logic Apps runtime을 VNet에 배치하지는 않습니다. 이는 종속성을 보안하는 데는 유용하지만 Logic App hosting plane을 보안하는 것은 아닙니다.

Azure AD B2B integration은 외부 identity(guest users)와 협업하고 Azure AD를 사용하여 애플리케이션에 대한 액세스를 관리하는 데 사용됩니다. 이는 사용자에 대한 authentication/authorization를 다루며 network isolation이나 Logic App runtime 보안을 다루지 않습니다. identity control도 중요하지만, B2B는 일반적으로 “Shipping Logic App을 보안하라”에 내포된 private VNet deployment와 traffic 제어를 제공하지 않습니다.

오답입니다. Azure Cosmos DB .NET SDK v3+에서 Container는 EndpointUri와 PrimaryKey로 직접 인스턴스화되지 않습니다. Container 객체는 CosmosClient에서 얻습니다(예: cosmosClient.GetContainer(databaseId, containerId)). client는 authentication, connection management, retries 및 기타 request pipeline behaviors를 처리하며, Container constructor는 이러한 기능을 이런 방식으로 제공하지 않습니다.

오답입니다. Cosmos DB .NET SDK v3+에서 Database는 EndpointUri와 PrimaryKey를 사용하는 constructor 호출로 생성되지 않습니다. 먼저 CosmosClient를 생성한 다음 Database 참조를 얻거나(예: cosmosClient.GetDatabase(databaseId)) CreateDatabaseIfNotExistsAsync를 통해 생성합니다. credentials 및 endpoint configuration은 Database가 아니라 CosmosClient에 속합니다.

"예"라고 답하는 것은 올바르지 않습니다. X.509 certificate를 사용하여 VM을 Azure Resource Manager에 인증하는 것은 예상되는 VM workload identity 패턴이 아니기 때문입니다. certificate는 service principal(app registration)의 credential로 사용할 수 있지만, 그러려면 Azure AD application을 만들고 관리해야 하며, VM에 private key를 설치하고 보호하고, rotation/expiry도 처리해야 합니다. 반면 managed identity를 사용하면 VM은 secret을 저장하지 않고 IMDS를 통해 token을 획득한 다음, 필요한 resource group 범위로 지정된 RBAC assignment를 사용할 수 있습니다. 따라서 이 맥락에서 certificate 기반 솔루션은 목표를 충족하는 것으로 간주되지 않습니다.

Reader 역할을 할당하는 것은 인증 메커니즘이나 token 획득 방법을 제공하지 않기 때문에 Yes라고 답하는 것은 올바르지 않습니다. VM은 OAuth 2.0 access token을 요청하기 위해 Azure AD 기반 ID(managed identity 또는 service principal)가 필요하며, 그 후에야 RBAC가 ARM 작업 허용 여부를 결정합니다. Reader는 인증이 완료된 후 읽기 권한만 부여할 뿐, token 검색을 가능하게 하지는 않습니다. 결과적으로 이 솔루션은 ARM access token을 획득해야 한다는 요구 사항을 충족하지 않습니다.

아니요는 올바르지 않습니다. 제안된 솔루션은 VM 기반 managed identity가 Azure service용 토큰을 요청하도록 의도된 정확한 방법이기 때문입니다. local managed identity endpoint는 Azure resource 자체에서 실행되는 워크로드를 위해 설계되었으며, PowerShell은 이를 직접 호출할 수 있습니다. 유일한 주의 사항은 VM에 managed identity가 활성화되어 있어야 하고 해당 identity에 필요한 RBAC 권한이 있어야 한다는 점이지만, token 획득 방법 자체는 올바릅니다.

AddRuleAsync는 subscription rule/filter를 추가하거나 업데이트합니다. TrueFilter는 모든 메시지와 일치하지만, 문제에서 이미 메시지가 subscription으로 전송되고 있다고 했으므로(portal에서 확인 가능), routing 및 filtering은 문제가 아닙니다. 또한 rule을 추가하는 것은 메시지 소비를 시작하지 않으며, 단지 어떤 메시지가 subscription으로 전달되는지에만 영향을 줍니다.

이 코드는 SubscriptionClient를 생성하는 구문이며, 시나리오에서 이미 수행했다고 명시되어 있습니다(“올바른 세부 정보를 제공하여 subscription client object를 생성하고 초기화”). 인스턴스화만으로는 메시지 수신이 시작되지 않습니다. subscription에서 실제로 메시지를 소비하려면 여전히 handler를 등록하거나 수신 루프를 구현해야 합니다.

CloseAsync는 client를 종료하고 네트워크 리소스를 해제합니다. 이를 호출하면 모든 수신이 중지되므로 필요한 작업과는 반대입니다. CloseAsync는 메시지 소비를 시작하기 위한 것이 아니라, 처리가 완료된 후 정상 종료 시 사용됩니다.

오답입니다. Azure AD B2C는 social identity와 사용자 지정 user flow를 사용하는 고객 대상(외부) identity 시나리오를 위해 설계되었습니다. 문제는 Azure AD(workforce tenant)를 사용하는 내부 직원용 웹사이트를 설명합니다. 직원의 경우 일반적으로 B2C가 아니라 Azure AD (Microsoft Entra ID)를 직접 사용하고 Conditional Access를 통해 MFA를 요구합니다.

오답입니다. Azure AD Application Proxy는 Azure AD를 통해 외부에서 액세스할 수 있도록 on-premises 애플리케이션을 안전하게 게시하는 데 사용됩니다. Azure에서 호스팅되는 내부 웹사이트에는 필요하지 않으며, 그 자체로 MFA를 구현하지도 않습니다. 이를 사용하더라도 MFA는 일반적으로 Application Proxy만으로가 아니라 Conditional Access를 통해 적용됩니다.

오답입니다. “Baseline policies”는 레거시 방식이며 대부분 Security Defaults와 Conditional Access로 대체되었습니다. 사용 가능하더라도 baseline/security defaults는 tenant 전체에 적용되며, 특정 애플리케이션에 대한 전용 Conditional Access policy만큼 세분화되어 있지 않습니다. 문제는 웹사이트에 MFA를 구현하라고 묻고 있으며, 이는 app을 대상으로 하는 Conditional Access policy로 수행하는 것이 가장 적절합니다.

Telemetry.Context.Cloud.RoleInstance는 App Service 인스턴스 또는 VM과 같이 telemetry를 내보낸 특정 compute 인스턴스를 식별합니다. 이는 scale-out 환경에서 node별 문제를 진단하는 데 도움이 될 수 있지만, 데이터베이스 호출에 대한 dependency tracking을 정의하거나 활성화하지는 않습니다. 이것은 호스트 metadata이지 dependency 자체를 표현하는 데 필요한 dependency telemetry 속성이 아닙니다. 따라서 여기서는 솔루션의 일부가 아닙니다.

Telemetry.Context.Operation.Id는 telemetry 항목을 더 넓은 request 또는 distributed trace와 연결하는 데 사용되는 correlation context 속성입니다. correlation은 중요하지만, 이 문제는 third-party 데이터베이스에 대해 dependency tracking이 작동하도록 하기 위해 어떤 dependency telemetry 속성을 사용해야 하는지를 묻고 있습니다. dependency 항목 자체는 주로 Id 및 Name과 같은 필드로 정의되며, Operation.Id는 더 넓은 context로서 SDK에 의해 자동으로 전달되는 경우가 많습니다. 따라서 주어진 선택지 중에서는 최선의 답이 아닙니다.

Telemetry.Context.Session.Id는 telemetry를 사용자 또는 클라이언트 session과 연결하기 위한 용도이며, 가장 일반적으로는 대화형 애플리케이션 시나리오에서 사용됩니다. 데이터베이스에 대한 server-side Web API dependency 호출은 dependency로 추적되기 위해 session context에 의존하지 않습니다. 이 속성은 dependency 작업을 식별하지도 않고 dependency telemetry에 올바르게 표시되도록 하지도 않습니다. 따라서 요구 사항과 관련이 없습니다.