Microsoft AZ-305

Conditional Access policies는 사용자가 Microsoft Entra ID를 통해 애플리케이션에 인증하는 방식을 제어합니다(예: MFA 요구, 규정 준수 device, named locations). 이는 URL을 통한 blob에 대한 시간 제한 액세스를 부여하는 기본 메커니즘이 아니며, SAS 기반 액세스는 Conditional Access의 적용을 전혀 받지 않을 수도 있습니다. 또한 Conditional Access는 blob 액세스에 대해 리소스별 만료를 본질적으로 단순하게 제공하지 않습니다.

Certificates는 Azure blob에 대한 임시 액세스를 부여하는 일반적이거나 권장되는 방법이 아닙니다. certificates는 특정 인증 시나리오(예: client certificates, service principals)에 사용될 수 있지만, Blob Storage 액세스에 대해 SAS가 제공하는 기본 제공 리소스 범위 및 시간 제한 권한 모델을 제공하지 않습니다. 또한 certificate 발급/교체 관리는 이 요구 사항에 불필요한 복잡성을 추가합니다.

Storage account access keys는 전체 storage account에 대한 광범위한 액세스를 부여하는 높은 권한의 장기 비밀입니다. 이를 10명의 사용자와 공유하는 것은 최소 권한 원칙을 위반하며, 수동 교체 없이 “4월만” 액세스를 강제하기 어렵게 만듭니다. key가 유출되면 공격자는 key가 재생성될 때까지 모든 데이터에 액세스할 수 있으므로, 이는 좋지 않은 보안 설계 선택입니다.

Azure AD Privileged Identity Management (PIM)는 privileged role을 관리하고 관리 액세스를 위한 just-in-time elevation을 제공하는 데 사용되므로 오답입니다. 이는 상시 privileged 권한을 줄이고 privileged account에 대한 승인 workflow, 알림 및 access review를 지원합니다. 그러나 온-프레미스 application을 게시하거나, 원격 연결을 제공하거나, 내부 web app에 액세스하는 최종 사용자에게 SSO를 활성화하지는 않습니다. 따라서 이 시나리오의 핵심 요구 사항을 해결하지 못합니다.

Conditional Access policies는 사용자가 application에 액세스할 수 있는 조건(예: MFA 요구, 규정 준수 device, 신뢰할 수 있는 위치)을 제어할 뿐이므로 주된 정답으로는 오답입니다. 이는 VPN 액세스가 없는 원격 사용자에게 온-프레미스 web application을 노출하는 메커니즘을 제공하지 않습니다. Conditional Access는 추가 보안을 위해 Application Proxy 위에 계층적으로 적용할 수 있지만, application에 도달 가능하게 하고 SSO를 제공하는 데 필요한 기능 중 하나는 아닙니다. 이 시나리오는 핵심 솔루션 구성 요소를 묻고 있으며, 그것은 Application Proxy와 enterprise application 구성입니다.

Azure Arc는 Azure에서 server, Kubernetes cluster 및 data service를 관리하는 것과 같은 hybrid 및 multicloud resource management를 위한 것이므로 오답입니다. 이는 Azure governance, policy 및 management 기능을 비-Azure 환경으로 확장합니다. 그러나 온-프레미스 web application에 대한 원격 사용자 액세스를 제공하지 않으며, 이 시나리오의 Integrated Windows authentication SSO와도 관련이 없습니다. 따라서 제시된 요구 사항과는 무관합니다.

Azure Application Gateway는 SSL termination, path-based routing 및 Web Application Firewall integration과 같은 기능을 갖춘 HTTP/HTTPS traffic용 Layer 7 load balancer이므로 오답입니다. web application을 게시할 수는 있지만, VPN 없이 내부 app에 대한 원격 액세스를 위해 설계된 Azure AD 기반 reverse proxy service는 아닙니다. 또한 Integrated Windows authentication app에 대해 Azure AD Application Proxy가 사용하는 것과 같은 Azure AD preauthentication 및 KCD 기반 SSO 패턴을 기본적으로 제공하지도 않습니다. Application Proxy와 비교하면, 이 정확한 시나리오에 필요한 직접적인 identity integration이 부족합니다.

Azure AD (Entra ID) Identity Protection은 risk policy 및 report를 사용하여 identity risk(risky sign-in, risky user)를 탐지하고 remediation하기 위해 설계되었습니다. 이는 group에 대한 주기적이고 사용자 주도의 membership attestation workflow를 제공하지 않으며, self-reported need 또는 무응답을 기반으로 사용자를 group에서 자동 제거하지도 않습니다. 따라서 제시된 governance 및 recertification 요구 사항을 충족할 수 없습니다.

Group1을 Dynamic User membership으로 변경하면 user attribute(예: department, jobTitle, userType)를 평가하는 rule을 기반으로 membership이 자동화됩니다. 이는 모든 member가 자신이 여전히 group에 있어야 하는지 명시적으로 보고해야 한다는 요구 사항을 충족하지 않으며, 분기별 review/attestation 프로세스도 구현하지 않습니다. Dynamic group은 attribute 기반 access에는 적합하지만, 주기적인 access recertification에는 적합하지 않습니다.

Privileged Identity Management (PIM)는 eligible assignment, just-in-time activation, approval workflow, privileged assignment에 대한 access review를 통해 privileged access(Azure AD role, Azure resource role, privileged group)를 관리하는 데 중점을 둡니다. PIM에 review 기능이 포함될 수는 있지만, 이 문제는 self-attestation과 non-responder의 자동 제거를 포함한 일반적인 assigned group membership 평가에 관한 것입니다. Access Reviews가 직접적이고 기대되는 솔루션입니다.

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 보고서의 데이터 소스는 아닙니다.

Azure Logic Apps integration account는 엔터프라이즈 통합 시나리오(B2B/EDI 계약, 스키마, 맵, 인증서)에 사용되며 Logic Apps 워크플로를 지원합니다. 온-프레미스 Windows 파일 서버의 파일을 Azure Blob Storage로 대량 복사하기 위한 직접적이고 목적에 맞는 메커니즘은 제공하지 않습니다. Logic Apps가 일부 전송을 orchestration할 수는 있지만, integration account 자체는 이 시나리오를 위한 완전한 파일 복사 솔루션이 아닙니다.

Azure Analysis Services On-premises data gateway는 semantic model 및 보고 도구(예: Power BI)가 온-프레미스 데이터 원본에 안전하게 액세스할 수 있도록 연결을 제공하기 위한 것입니다. 파일 공유를 Azure Blob Storage로 복사하는 데이터 이동 서비스가 아닙니다. 이는 대량 파일 수집이 아니라 쿼리 연결을 가능하게 하므로, store1에 파일 복사본을 저장해야 하는 요구 사항을 충족하지 않습니다.

Azure Batch account는 compute node 풀 전반에 걸쳐 작업을 예약하여 대규모 병렬 및 고성능 컴퓨팅 워크로드를 실행하는 데 사용됩니다. 데이터 전송 또는 마이그레이션 서비스가 아닙니다. Batch job이 데이터가 Azure에 들어온 후 이를 처리할 수는 있지만, 온-프레미스 파일 서버의 데이터를 Azure Blob Storage로 복사하는 간단하고 관리되는 메커니즘을 완전한 솔루션으로 제공하지는 않습니다.

Recovery Services vault와 Windows Server Backup은 주로 backup/restore 접근 방식입니다. VM1의 데이터를 보호할 수는 있지만, Toronto outage 중에는 사용자가 즉시 액세스할 수 없습니다. 먼저 대체 인프라로 restore해야 합니다. 이는 RTO를 증가시키며 지사 사무실 전반의 사용자 액세스 속도를 본질적으로 향상시키지 않습니다. 이는 빠르고 지속적인 파일 액세스가 아니라 데이터 보호를 해결합니다.

Azure blob containers와 Azure File Sync는 이 사용 사례에 적합한 조합이 아닙니다. Azure File Sync는 cloud endpoint로 Blob storage가 아니라 Azure file share(Azure Files)를 필요로 합니다. Blob은 object storage 및 archival에는 매우 적합하지만, 추가 서비스/gateway 없이는 일반적인 Windows file server 공유 폴더에 필요한 SMB share semantics를 제공하지 않습니다.

Recovery Services vault와 Azure Backup은 VM1을 보호하고 Azure 또는 다른 서버로 데이터를 restore할 수 있지만, 여전히 restore 기반 DR 방법입니다. 이미 대체 파일 서버를 프로비저닝하고 동기화해 두지 않았다면 outage 중 사용자는 공유 파일에 빠르게 액세스할 수 없습니다. 이 옵션은 내구성을 향상시키지만, 일반적으로 동기화된 cloud-backed file share 솔루션에 비해 더 높은 RTO를 초래합니다.

오답입니다. Azure Site Recovery는 주로 Azure VMs 및 일부 온-프레미스 서버와 같은 워크로드를 다른 지역으로 복제하여 disaster recovery를 제공하는 데 사용됩니다. 이는 Azure SQL Database backup retention 요구 사항을 충족하기 위한 표준 메커니즘이 아닙니다. ASR은 장기 데이터베이스 backup retention 및 아카이브보다는 business continuity(failover)를 다룹니다.

오답입니다. 자동 Azure SQL Database backups는 기본적으로 활성화되어 있으며 short-term retention 기간 내에서 point-in-time restore를 지원합니다. 지원되는 한도 내에서 STR을 조정할 수는 있지만, 일반적으로 이는 운영 복구(일/주)를 위한 것이지 수개월 또는 수년 보존을 위한 것이 아닙니다. 장기 규정 준수 보존은 STR만으로가 아니라 LTR로 처리합니다.

오답입니다. Geo-replication(또는 failover groups)은 읽기 가능한 secondary를 제공하고 지역 복원력을 위한 빠른 failover를 지원합니다. 이는 high availability/disaster recovery 기능이지 backup retention 기능이 아닙니다. Replicas는 논리적 손상을 전파할 수 있으며 보존 및 규정 준수 시나리오에 필요한 과거의 장기 backup chain을 제공하지 않습니다.

예는 오답입니다. Azure Traffic Analytics는 NSG flow log에서 허용 및 거부된 flow 추세를 보여줄 수 있지만, VM으로 향하는 packet이 허용되는지 또는 거부되는지를 정확한 per-flow 방식으로 직접 troubleshooting하기 위한 도구는 아닙니다. 이는 특정 connectivity 문제에 대한 결정론적 packet 검증보다는 network 전반의 traffic pattern, analytics 및 visualization에 중점을 둡니다. 이 시나리오에서 목표는 virtual machine에 영향을 주는 packet 허용/거부 동작을 식별하는 것이며, 이는 Network Watcher IP flow verify를 사용하거나 NSG flow log를 직접 검토하는 방식이 더 적합합니다. 따라서 제안된 솔루션이 목표를 충족한다고 말하는 것은 Traffic Analytics의 설계 목적을 과장하는 것입니다.

예는 오답입니다. Azure Advisor는 네트워크 packet flow를 캡처하거나 분석하지 않으며 VM 트래픽에 대한 허용/거부 결정을 제공하지 않기 때문입니다. Advisor는 운영 트래픽 진단이 아니라 모범 사례 권장 사항(비용 최적화, 보안 상태, 안정성, 성능)에 중점을 둡니다. 개선 사항을 제안할 수는 있지만, 특정 packet이 허용되었는지 또는 거부되었는지는 알려줄 수 없습니다.

이 옵션은 제안된 솔루션이 제시된 목표를 충족하기 때문에 오답입니다. 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이 아닙니다.