Microsoft AZ-104

오답입니다. 단순히 사용자를 group에 추가하거나 초대하는 것만으로는 Azure AD Premium P2 features가 자동으로 부여되지 않습니다. Group membership는 group-based licensing이 구성되어 있고 해당 group에 P2 license가 할당된 경우에만 도움이 되는데, 이 선택지에는 그 내용이 명시되어 있지 않습니다. 문구는 사용자를 group에 초대하라고 되어 있을 뿐, group을 통해 licenses를 할당하라고 하지는 않습니다. 따라서 이 작업만으로는 10명의 사용자가 모든 Premium features를 사용할 수 있다고 보장할 수 없습니다.

오답입니다. enterprise application 추가는 application integration, single sign-on, 그리고 service principal management에 사용됩니다. 이것은 사용자에게 Azure AD Premium P2 licenses를 할당하는 것과는 관련이 없습니다. tenant에 enterprise application이 존재한다고 해서 사용자가 Premium directory capabilities를 얻는 것은 아닙니다. 이 선택지는 문제의 licensing requirement를 해결하지 못합니다.

오답입니다. Directory roles는 Azure AD 내의 administrative permissions를 결정합니다. 예를 들어 User Administrator 또는 Global Administrator 같은 역할입니다. 하지만 이는 Azure AD Premium P2 features에 대한 license entitlement를 제공하지 않습니다. 사용자에게 admin role이 있어도 P2 license가 할당되지 않았다면 Premium features에 대한 access rights가 없을 수 있습니다. 따라서 directory role을 수정하는 것은 요구 사항을 충족하지 못합니다.

Azure Application Gateway는 Layer 7(HTTP/HTTPS) 로드 밸런서이자 리버스 프록시로, 종종 Web Application Firewall(WAF)과 함께 사용됩니다. 이는 웹 엔드포인트를 게시하고 보호하며 웹 트래픽을 백엔드로 라우팅하는 데 도움이 됩니다. SMB를 통해 온-프레미스 리소스에 대한 일반적인 네트워크 연결을 제공하지 않으며 VPN 터널을 생성하지도 않습니다. 따라서 webapp1이 온-프레미스 SMB 공유에 액세스하도록 해주지 못합니다.

Azure AD Application Proxy는 온-프레미스에 커넥터를 배치하고 Azure AD를 사용해 사전 인증을 수행함으로써 온-프레미스 웹 애플리케이션(HTTP/HTTPS)에 대한 안전한 원격 액세스를 제공하도록 설계되었습니다. 파일 공유 액세스나 SMB 프로토콜 포워딩을 위한 것이 아닙니다. Share1은 SMB 공유이므로 Application Proxy는 webapp1이 연결하는 데 필요한 네트워크 경로나 프로토콜 지원을 제공할 수 없습니다.

오답입니다. Web server logging은 URL, method, status code, timing data와 같은 HTTP 요청 및 응답 정보를 기록하지만, 일반적으로 HTTP 500 오류를 유발한 전체 internal 예외 세부 정보는 포함하지 않습니다. 따라서 실패가 발생했음을 확인하는 데는 유용하지만, 근본 원인이 필요한 개발자에게는 덜 유용합니다. 문제는 개발자에게 모든 오류 세부 정보를 제공하는 것을 강조하므로, application logging이 더 나은 첫 번째 조치입니다.

오답입니다. Azure Monitor workbook은 시각화 및 보고 도구일 뿐입니다. 이는 이미 수집되고 있는 로그나 metric에 의존하며, web app에 대한 진단 수집 자체를 활성화하지는 않습니다. 적절한 logging이 이미 켜져 있지 않다면, 먼저 workbook을 생성해도 새로운 실시간 오류 세부 정보는 제공되지 않습니다.

오답입니다. Service Health alerts는 Azure 플랫폼 중단, 유지 관리 이벤트, 또는 서비스 권고 사항을 관리자에게 알리도록 설계되었습니다. 이는 애플리케이션별 HTTP 500 실패를 수집하거나 web app의 요청별 진단 세부 정보를 제공하지 않습니다. 이 옵션은 개발자가 간헐적인 서버 오류의 internal 원인을 조사하는 데 도움이 되지 않습니다.

예는 오답인 이유는 Subscriptions 블레이드의 Programmatic deployment가 특정 리소스 그룹에서 리소스가 생성된 날짜/시간을 확인하기 위한 적절하고 직접적인 방법이 아니기 때문입니다. template 기반 배포의 생성 시점은 리소스 그룹의 배포 기록(RG1 -> Deployments) 또는 RG1로 필터링한 Activity log에서 확인하는 것이 가장 좋습니다.

automation runbook을 생성하는 것은 Service Manager와 Azure alerts를 통합하기 위한 첫 단계가 아닙니다. Runbooks(Azure Automation)는 remediation 또는 커스텀 통합을 실행하는 데 사용할 수 있지만, ticket 생성 로직을 직접 구축하고 유지 관리해야 합니다(대개 APIs 사용). 이 문제는 Service Manager에서 alert가 설정되도록 하기 위해 먼저 무엇을 해야 하는지를 묻고 있으며, 표준 전제 조건은 ITSM Connector 통합입니다.

function app을 배포하는 것은 Azure Monitor alerts를 수신한 뒤 Service Manager APIs를 호출하는 커스텀 webhook endpoint를 구현하는 데 사용할 수 있습니다. 하지만 이는 커스텀 솔루션이며 AZ-104 맥락에서 기대되는 첫 단계가 아닙니다. Microsoft는 Service Manager 같은 ITSM 도구와 Azure Monitor를 통합하기 위해 IT Service Management Connector를 제공하므로, 기본 요구 사항에는 Function App이 필요하지 않습니다.

notification을 생성하는 것만으로는 충분하지 않습니다. notification(email/SMS/push)은 사람이나 endpoint로 전달될 뿐, Service Manager 내부에 alert/incident 레코드를 생성하지는 않습니다. Service Manager는 work item을 생성하기 위한 통합 경로가 필요합니다. Azure Monitor에서는 일반적으로 단순 notification이 아니라 ITSM Connector에 연결된 action group을 통해 이 통합을 구현합니다.

오답입니다. MFA Server blade의 Providers는 multi-factor authentication integration 및 legacy MFA Server 관련 settings를 구성하는 데 사용됩니다. 이러한 settings는 users가 인증하는 방식에는 영향을 주지만, Azure AD-joined devices에서 로컬 Windows administrator membership은 제어하지 않습니다. 이 문제는 join 이후의 device administration에 관한 것이지 authentication policy에 관한 것이 아닙니다. 따라서 MFA Server settings는 요청된 구성과 관련이 없습니다.

오답입니다. Users blade의 User settings는 Azure AD 내에서 user 관련 옵션과 profile 수준 구성을 관리합니다. 그러나 Azure AD-joined Windows devices의 로컬 Administrators group에 누가 추가되는지를 결정하는 tenant-wide control은 제공하지 않습니다. 구성 대상이 user account이기는 하지만, 요구 사항의 범위는 join된 모든 computers이므로 이는 device configuration 문제입니다. 이런 이유로 Users blade는 이를 구성하는 올바른 위치가 아닙니다.

오답입니다. Groups blade의 General settings는 naming conventions, expiration, self-service group features와 같은 group 동작을 관리하기 위한 것입니다. 이는 Azure AD-joined devices에서 어떤 users가 로컬 administrator 권한을 받는지를 정의하지 않습니다. 문제는 모든 join된 computers에 적용되는 기본 제공 Azure AD device administration setting을 묻고 있으며, 이는 Groups가 아니라 Devices 아래에 있습니다. 따라서 이 옵션은 요구 사항을 충족하지 않습니다.

Application Gateway 5개는 web app을 배포하는 데 필요하지 않습니다. Application Gateway는 고급 라우팅, TLS 종료, 보호를 위해 사용되는 Layer 7 로드 밸런서/WAF입니다. 상당한 비용과 복잡성을 추가하며, 특정 요구 사항(WAF, 경로 기반 라우팅, ILB를 통한 프라이빗 액세스 등)이 있을 때만 정당화됩니다. App Service 배포의 전제 조건이 아닙니다.

App Service plan 10개는 app별 격리 및 독립적 스케일링을 가능하게 하지만, 각 plan이 자체 컴퓨팅 리소스를 프로비저닝하고 과금되므로 일반적으로 가장 비싼 접근 방식입니다. 이는 app에 서로 다른 SKU, 지역, OS 유형 또는 엄격한 격리가 필요한 경우에만 적절합니다. 비용 최소화 관점에서는 일반적으로 오답입니다.

Azure Traffic Manager는 엔드포인트/지역 간 DNS 기반 글로벌 라우팅 및 장애 조치를 제공합니다. web app을 배포하는 데 필요하지 않으며 App Service plan의 필요성을 대체하지도 않습니다. 다중 지역 배포가 있거나 성능/장애 조치 라우팅이 필요할 때 사용되며, 10개의 web app을 배포하기 위한 전제 조건을 넘어서는 내용입니다.

Application Gateway 1개는 Layer 7 라우팅 및 WAF를 위해 하나 이상의 web app 앞단에 둘 수 있지만, App Service app을 배포하기 전에 필수는 아닙니다. 또한 추가 비용을 유발합니다. 시나리오에서 WAF, 프라이빗 인그레스 또는 고급 라우팅이 명시적으로 요구되지 않는 한, Application Gateway를 식별/배포하는 것은 올바른 전제 조건이 아닙니다.

Desired State Configuration(DSC) management를 사용하도록 설정(일반적으로 Azure Automation State Configuration/DSC를 통해)은 구성 관리 기능입니다. 이는 agent/extension 및 pull server 모델을 사용하여 게스트 OS에 구성을 적용합니다. 이는 일반적으로 VM이 실행 중인 상태에서 수행되며, 본질적으로 VM을 중지/할당 해제할 필요가 없습니다. DSC는 적용하는 구성에 따라 서비스(또는 OS)를 재시작할 수는 있지만, 관리 기능 자체를 활성화하는 행위는 시험에서 다운타임을 유발하는 것으로 기대되지 않습니다.

기존 Azure VM에 500-GB managed disk를 추가(attach)하는 것은 일반적으로 온라인 작업입니다. VM이 실행 중인 상태에서 새로운 managed data disk를 attach할 수 있으며, 플랫폼 차원에서 다운타임이 필요하지 않습니다. attach 후에는 게스트 OS 내부에서 디스크를 초기화/파티션/포맷해야 하는데, 이 또한 온라인으로 수행할 수 있습니다. 이는 AZ-104의 일반 포인트로, data disk attach는 보통 hot-add입니다.

Puppet Agent extension을 추가하는 것은 VM extension 배포를 통해 Azure VM Agent가 수행합니다. VM extension은 VM이 실행 중인 상태에서 설치 및 업데이트되도록 설계되었으며, 일반적으로 재부팅이나 할당 해제가 필요하지 않습니다. extension이 소프트웨어를 설치하고 구성에 따라 서비스를 재시작할 수는 있지만, extension을 추가하는 행위 자체는 AZ-104에서 다운타임을 유발하는 플랫폼 작업으로 간주되지 않습니다.

Yes는 오답입니다. Microsoft.ClassicNetwork를 unregister하는 것은 legacy classic networking resource provider에만 영향을 주며 새로 생성되는 NSG에 security rules를 적용하지 않습니다. TCP port 8080에 대한 deny rule을 생성하지도 않고, ARM-based virtual networks 간의 트래픽을 제어하지도 않습니다. 요구 사항은 생성 시점에 NSG를 자동으로 구성하는 것이므로 governance 또는 deployment tooling이 필요합니다. 따라서 Yes라고 답하면 provider registration이 NSG 동작을 강제할 수 있다고 잘못 가정하게 됩니다.

오답입니다. 5개의 독립형 virtual machines를 배포하는 것은 virtual machine scale set을 전혀 생성하지 않으므로, 문제의 핵심 요구 사항을 충족하지 못합니다. 각 VM에서 Availability Zones를 조정하는 것은 구성 작업만 더 늘릴 뿐이며, scale set orchestration, 중앙 집중식 관리 또는 단순화된 scaling 동작을 제공하는 데 아무런 도움이 되지 않습니다. 이 접근 방식은 각 VM을 개별적으로 생성하고 관리해야 하므로 운영 측면에서도 더 느립니다. 또한 VMSS가 특별히 제공하도록 설계된 일관성과 자동화 이점도 부족합니다.

오답입니다. 5개의 개별 virtual machines를 배포하고 해당 size 설정을 수정하더라도 여전히 virtual machine scale set이 되지는 않습니다. VM size는 compute capacity에 영향을 주는 것이지 배포 모델에 영향을 주는 것이 아니므로, size를 변경해도 instances가 scale set으로 관리되는지 여부나 전체 솔루션이 얼마나 빨리 배포될 수 있는지에는 아무런 관련이 없습니다. 이 선택지는 VM별 관리 작업을 불필요하게 추가하며, 단일 확장 가능한 resource에 대한 요구 사항도 충족하지 못합니다. 따라서 기술적으로도 맞지 않고 VMSS를 사용하는 것보다 효율성도 떨어집니다.

오답입니다. ScaleSetVM orchestration mode는 기존 uniform VMSS 모델을 의미하며, 제공된 선택지와 현재 Azure orchestration 가이드를 고려할 때 여기서는 최선의 정답이 아닙니다. scale set을 생성하기는 하지만, 시험의 구분에서는 일반적으로 하나의 scale set resource 아래에서 여러 VM instances를 더 빠르고 더 유연하게 배포할 수 있는 VM orchestration mode를 선호합니다. Uniform mode는 instances가 더 동일하게 취급되고 기존 scale set 모델을 따르기 때문에 더 제한적입니다. 문제는 가장 빠른 배포 방식을 묻고 있고 VM orchestration mode를 선택지로 포함하고 있으므로, D는 최선의 정답이 아닙니다.

Yes는 오답입니다. resource lock은 네트워크 보안 적용 기능이 아니기 때문입니다. lock은 NSG 내용을 검사하거나, deny rule을 배포하거나, TCP port 8080의 트래픽이 VNet 전반에서 차단되도록 보장하지 않습니다. lock이 subscription의 리소스에 상속되더라도 삭제 또는 수정과 같은 management 작업만 제한합니다. 요구 사항은 NSG에 대한 자동 rule 적용에 관한 것이며, 이는 lock으로 제공할 수 없습니다.

오답입니다. Azure Application Gateway는 Layer 7(HTTP/HTTPS) load balancer이며 WAF 기능을 제공할 수 있지만, 온-프레미스 네트워크를 Azure VNet에 연결하지는 않습니다. On-premises data gateway는 Microsoft cloud 서비스(Power BI, Power Apps, Logic Apps)에서 온-프레미스 데이터 원본에 안전하게 액세스하기 위해 사용되며, site-to-site network 연결이나 latency 최적화 WAN 설계를 위한 것이 아닙니다.

오답입니다. 일반적이고 권장되는 아키텍처는 하나의 Virtual WAN과 여러 Virtual Hub입니다. 세 개의 별도 Virtual WAN을 생성하면 관리 및 라우팅 도메인이 분절되며, latency를 본질적으로 최소화하지도 않습니다. 또한 단일 vWAN이 제공하는 중앙집중형 글로벌 transit 이점을 잃게 되어 사이트와 Azure 네트워크 간 상호 연결이 더 복잡해질 수 있습니다.

오답입니다. On-premises data gateway는 네트워킹 구성 요소가 아니며, 특정 Microsoft 서비스에 대한 애플리케이션 수준 데이터 연결을 가능하게 합니다. Azure Application Gateway는 웹 트래픽 관리용이며 site-to-site VPN/ExpressRoute 연결을 제공하지 않습니다. 이 옵션은 datacenter를 VNet에 연결하거나 지리적으로 분산된 사이트 간 network latency를 최적화하는 요구 사항을 충족하지 못합니다.

Allow gateway transit는 gateway를 포함하는 VNet에서 사용되며, peered VNet이 해당 gateway를 remote gateway로 사용할 수 있게 합니다. 이 설정은 특히 site-to-site 또는 ExpressRoute 시나리오에서 VNet 간 gateway 공유와 관련이 있지만, 이미 설치된 P2S 클라이언트의 route table을 그 자체로 업데이트하지는 않습니다. 이 문제에서는 클라이언트가 VNet1에 연결할 수 있고 peering이 이미 Azure 측 연결을 허용하고 있으므로, 문제는 gateway transit를 활성화하는 것만으로 해결되지 않습니다. 클라이언트는 여전히 VNet2가 VPN tunnel을 통해 도달되어야 한다는 것을 알기 위해 새로 고쳐진 route 정보가 필요합니다.

VNet2에서 Allow gateway transit를 선택하는 것은 올바르지 않습니다. 왜냐하면 VNet2에는 VPN gateway가 없기 때문입니다. Azure peering에서 gateway가 있는 VNet은 Allow gateway transit를 사용해 이를 노출하고, peered VNet은 Use remote gateways를 사용해 이를 소비합니다. gateway-sharing 설정이 관련이 있다고 하더라도, 이 특정 옵션은 잘못된 쪽에 적용된 것입니다. 따라서 Client1이 VNet2에 도달하지 못하는 문제를 해결하지 못합니다.

BGP는 호환되는 VPN device 및 gateway와 동적 route 교환에 사용되지만, 이 시나리오의 gateway는 static routing을 사용합니다. 더 중요한 점은, 설명된 문제는 Azure와 on-premises 간 동적 route 교환 부족이 아니라는 것입니다. 왜냐하면 on-premises는 이미 VNet2에 성공적으로 도달하고 있기 때문입니다. 실패 원인은 point-to-site 클라이언트에 peered VNet에 대한 업데이트된 도달 가능 정보가 없다는 점에만 해당합니다. 여기서 BGP를 활성화하는 것은 필요한 해결책도 아니고 직접적인 해결책도 아닙니다.

IP flow verify는 특정 트래픽 flow(소스/대상 IP, port, protocol)가 VM의 NIC 또는 subnet에서 NSG 규칙에 의해 허용되는지 또는 거부되는지를 검증합니다. 이는 보안/라우팅 권한 확인이며 성능 도구가 아닙니다. latency, round-trip time을 측정하거나 시계열 성능 메트릭을 제공하지 않으므로 “평소보다 느림”을 정량화하는 데 도움이 되지 않습니다.

Connection troubleshoot는 소스와 대상 간 연결성을 확인하고 실패가 발생하는 위치(NSG, UDR, DNS, firewall 등)를 식별하는 on-demand 진단입니다. 단일 테스트 동안 일부 latency 관련 세부 정보를 제공할 수는 있지만, 이 문제가 요구하는 것처럼 시간에 따른 평균 RTT를 지속적으로 모니터링하거나 보고하기 위한 용도는 아닙니다.

NSG flow logs는 NSG를 통과하는 IP 트래픽에 대한 정보(허용/거부 flow, 5-tuple, counts/bytes)를 기록하며 트래픽 분석, 감사, 보안 조사에 사용됩니다. 이는 end-to-end latency 또는 RTT를 캡처하지 않습니다. 트래픽이 흐르는지 확인하는 데는 사용할 수 있지만, 요구되는 평균 RTT 메트릭을 제공하지는 않습니다.

Basic Load Balancer는 active-active 동작과 자동 장애 조치가 필요한 최신 NVA architecture에 적합한 선택이 아닙니다. 이는 기능이 더 적은 legacy SKU이며 production network virtual appliance 배포에 권장되는 옵션이 아닙니다. Azure certification 시나리오에서는 문제가 명시적으로 Basic으로 제한하지 않는 한 Standard Load Balancer가 예상되는 답입니다. 따라서 Basic을 선택하는 것은 모범 사례나 필요한 기능 집합과 맞지 않습니다.

이 옵션이 틀린 이유는 Azure gateway/NVA 시나리오의 HA Ports rule에서는 Floating IP를 활성화하면 안 되기 때문입니다. Floating IP를 활성화하면 이 load-balancing 패턴에 필요하지 않은 방식으로 packet 처리 동작이 변경되며, NVA와 함께 사용하는 HA Ports에 대한 Microsoft 지침과도 일치하지 않습니다. HA Ports 자체는 맞지만 Floating IP가 포함되어 있으므로 전체 옵션은 틀립니다. 시험에서는 이것이 미묘하지만 중요한 차이입니다.

두 개의 backend pool은 필요하지 않습니다. backend pool에는 Production subnet의 두 대상 서비스가 아니라 검사를 수행하는 두 개의 NVA가 포함되어야 하기 때문입니다. 서로 다른 IP 주소를 가진 서비스는 appliance 뒤쪽의 downstream 대상이므로, 이 설계에서 각각 별도의 load balancer backend pool이 필요한 것은 아닙니다. 필요한 것은 NVA용 하나의 backend pool과 서로 다른 서비스 대상을 처리하기 위한 별도의 load-balancing rule입니다. 두 개의 backend pool을 사용하면 이 architecture에서 load balancer의 역할을 잘못 표현하게 됩니다.