Practice Test #5

아니오. 하이브리드 클라우드 모델은 회사가 항상 private cloud 모델에서 마이그레이션해야 한다는 요구사항이 아니다. 하이브리드는 단순히 private 및 public cloud 환경을 결합하는 것을 의미하며, 일반적으로 networking (site-to-site VPN 또는 ExpressRoute), identity (Microsoft Entra ID), 그리고 통합된 management/monitoring과 같은 통합을 포함한다. 회사는 완전히 on-premises(반드시 “private cloud”일 필요는 없음)에서 시작한 뒤, 특정 워크로드(backup, DR, dev/test)를 위해 Azure를 도입하여 하이브리드가 될 수 있다. 또는 회사가 public cloud에서 시작한 후, compliance, data residency, 또는 low-latency 요구를 위해 private cloud/on-premises 리소스를 나중에 추가하는 경우도 있으며, 이 또한 하이브리드이다. 잘못된 “예”는 필수적인 순서(private → hybrid)를 암시하지만, 이는 정의의 일부가 아니다. 시험 관점에서는 정의에 집중하라: hybrid = private와 public의 혼합이며, 필수 마이그레이션 경로가 아니다.

예. 회사는 public cloud를 사용하여 내부 네트워크의 용량을 확장할 수 있습니다. 이는 전형적인 hybrid 사용 사례입니다. 즉, 핵심 시스템은 on-premises에 유지하면서 수요가 급증하거나 추가 하드웨어 구매를 피하고 싶을 때 Azure를 사용해 compute, storage 또는 services 용량을 추가할 수 있습니다. 예로는 cloud bursting(Azure에서 일시적으로 추가 애플리케이션 인스턴스를 실행), backups/archives를 위한 storage 확장, 또는 VPN/ExpressRoute를 통해 on-prem과 연결된 Azure 기반 virtual networks를 추가하여 address space를 확장하고 추가 workloads를 호스팅하는 방식이 있습니다. 이는 Cost Optimization(과도한 사전 프로비저닝 대신 pay-as-you-go), Reliability(추가 용량 및 DR 옵션), 그리고 Scalability/Performance Efficiency(elastic resources)를 지원합니다. AZ-900 관점에서 이 문장은 public cloud 리소스를 on-prem 네트워크와 통합하여 용량을 보강할 수 있으므로 전반적으로 참입니다.

아니요. public cloud 모델에서는 cloud 리소스에 대한 액세스가 회사의 “guest users”로만 제한되지 않습니다. public cloud는 인프라의 소유 및 제공 모델(공급자 소유, multi-tenant)을 의미하며, guest 계정만 리소스에 액세스할 수 있다는 제한을 의미하지 않습니다. 조직의 Azure 리소스에 대한 액세스는 Microsoft Entra ID tenants, Azure RBAC roles, conditional access, network controls와 같은 identity 및 authorization 메커니즘으로 제어됩니다. 사용자는 조직이 허용하는 범위에 따라 내부 직원(member users), 외부 협업자(B2B를 통한 guest users), applications/service principals, managed identities, 자동화된 프로세스 등이 될 수 있습니다. 이 잘못된 문장은 “public cloud” 개념을 “public access”와 혼동하고 있습니다. 리소스는 본질적으로 public에 공개되어 있지 않으며, 명시적으로 노출(예: public endpoints)하고 액세스를 승인하지 않는 한 subscription/tenant에 대해 private입니다.

정답: D. Azure Advanced Threat Protection (ATP). “센서를 사용하여 위협을 모니터링”은 Azure ATP(현재 Microsoft Defender for Identity)와 일치합니다. Azure ATP는 센서(일반적으로 domain controller에 설치하거나 standalone sensor를 통해)를 배포하여 네트워크 트래픽과 보안 이벤트를 수집한 다음, 이를 분석하여 정찰(reconnaissance), 자격 증명 탈취(credential theft) 기법, 의심스러운 lateral movement와 같은 identity 관련 위협을 탐지합니다. “sensors”라는 명시적 언급은 시험 문제에서 이 제품을 가리키는 핵심 단서입니다. 다른 선택지가 틀린 이유: - A. Azure Monitor: 리소스 및 앱에 대한 metrics/logs를 수집하지만, 전용 identity 위협 센서를 제공하지는 않습니다. - B. Azure Security Center (Defender for Cloud): 보안 posture management 및 workload protection에 초점을 둡니다. telemetry를 위해 agents/extensions를 사용하지만, 시험에서 “using sensors”라는 표현은 전통적으로 Azure ATP/Defender for Identity와 연결됩니다. - C. Azure AD Identity Protection: Azure AD에서 risky users/sign-ins를 탐지하지만, 동일한 의미의 “sensors”에 의존하지 않습니다. Azure AD signals 및 risk analytics를 사용합니다.

정답: C. Azure Active Directory (Azure AD) Identity Protection. “조건에 따라” Azure MFA를 적용한다는 것은 위험 기반 또는 조건부 적용과 연결됩니다. Azure AD Identity Protection은 사용자 위험(user risk) 및 로그인 위험(sign-in risk)을 평가하며(감지된 이상 징후 및 유출된 자격 증명 신호 기반), 위험 임계값에 도달하면 암호 변경을 요구하거나 MFA를 요구하는 방식으로 자동으로 교정(remediate)할 수 있습니다. AZ-900 유형의 문제에서 조건/위험 기반 MFA 적용과 가장 직접적으로 연관된 서비스가 이것입니다. 다른 선택지가 틀린 이유: - A. Azure Monitor: ID 및 액세스 제어 서비스가 아닙니다. - B. Azure Security Center (Defender for Cloud): MFA 활성화를 권장하고 보안 상태를 개선할 수는 있지만, 로그인에 대한 MFA 조건을 강제 적용하지는 않습니다. - D. Azure Advanced Threat Protection (Defender for Identity): 센서를 사용해 ID 공격을 탐지하고 조사하지만, MFA 조건을 강제 적용하는 제어 플레인은 아닙니다. 해당 강제 적용은 Azure AD 기능(Identity Protection/Conditional Access)을 통해 수행됩니다.

정답: D. SaaS 솔루션을 구성하는 것입니다. SaaS 모델에서는 클라우드 제공자가 전체 애플리케이션 스택을 제공하고 운영합니다. 귀하의 책임은 주로 테넌트/애플리케이션 구성 수준에 있습니다. 즉, 사용자 및 역할 설정, 기능 구성, 워크플로, 정책, 통합을 구성하고, 서비스가 규정을 준수하는 방식으로 사용되도록 보장하는 것입니다(예: SaaS 제품 내에서 제공되는 보존(retention) 또는 액세스 제어를 구성). 다른 선택지가 틀린 이유: A(고가용성 구성)는 일반적으로 SaaS에서 제공자의 책임입니다. 제공자는 게시된 SLA를 충족하도록 서비스를 설계 및 운영하며, 중복성, 장애 조치(failover), 패치를 처리합니다. B(확장성 규칙 정의)는 일반적으로 SaaS에서 고객의 작업이 아닙니다. 기본 컴퓨팅 리소스나 autoscale 설정을 관리하지 않으며, 제공자가 서비스를 확장합니다. C(SaaS 솔루션 설치)는 SaaS가 즉시 사용 가능한 애플리케이션으로 소비되기 때문에 틀립니다. 애플리케이션 바이너리나 서버를 설치하거나 유지보수하지 않습니다.

정답 선택: “Help + support”(또는 “Support + troubleshooting”) 블레이드를 사용하여 할당량 증가를 위한 지원 요청을 생성합니다. 이것이 정답인 이유: Subscription 할당량 증가는 Microsoft가 지원 요청 워크플로를 통해 처리합니다. Azure portal에서 일반적으로 Help + support로 이동한 다음 Support request를 생성하고, “Service and subscription limits (quotas)”와 관련된 이슈 유형을 선택합니다. 이는 vCPU cores, networking limits 또는 기타 subscription 수준 할당량과 같은 제한 증가를 요청하는 표준 경로입니다. 다른 블레이드가 틀린 이유: Virtual machines, Resource groups, SQL databases 등의 블레이드는 해당 리소스를 관리하기 위한 것이며, subscription 수준의 할당량 증가 요청 프로세스를 제공하지 않습니다. 할당량이 VMs와 관련되어 있더라도, 요청은 VM 블레이드가 아니라 Support를 통해 제출됩니다.