CloudPass LogoCloud Pass
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
Certifications
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
Microsoft AZ-900
Microsoft AZ-900

Practice Test #2

50개 문제와 45분 시간 제한으로 실제 시험을 시뮬레이션하세요. AI 검증 답안과 상세 해설로 학습하세요.

50문제45분700/1000합격 점수
기출 문제 보기

AI 기반

3중 AI 검증 답안 및 해설

모든 답안은 3개의 최고 AI 모델로 교차 검증하여 최고의 정확도를 보장합니다. 선택지별 상세 해설과 심층 문제 분석을 제공합니다.

GPT Pro
Claude Opus
Gemini Pro
선택지별 상세 해설
심층 문제 분석
3개 모델 합의 정확도

기출 문제

1
문제 1
(2개 선택)

Azure web app이 있습니다. iPhone에서 web app의 설정을 관리해야 합니다. 사용할 수 있는 Azure 관리 도구 두 가지는 무엇입니까? 각 정답은 완전한 솔루션을 제시합니다. 참고: 각 정답 선택은 1점입니다.

Azure CLI는 App Service를 포함한 Azure 리소스를 관리하기 위한 command-line 도구입니다. 그러나 일반적으로 로컬 설치와 지원되는 OS/shell 환경이 필요합니다. iPhone은 Azure CLI를 네이티브로 설치하고 실행하는 표준 플랫폼이 아니므로, 시험 문맥에서 휴대폰에서 직접 web app 설정을 관리하기 위한 완전한 솔루션으로 간주되지 않습니다.

Azure portal은 iPhone을 포함한 브라우저를 통해 접근 가능한 웹 기반 관리 인터페이스입니다. application settings, configuration, scaling, deployment slots, monitoring 등 Azure web app(App Service)에 대한 전체 UI 기반 관리를 제공합니다. 로컬 설치가 필요 없고 모바일 브라우저로 동작하므로 완전한 솔루션입니다.

Azure Cloud Shell은 Azure에서 호스팅되는 브라우저 접근형 shell 환경입니다. iPhone에서 Azure portal 내 Cloud Shell을 열고 Azure CLI 또는 Azure PowerShell 명령을 실행하여 web app의 설정을 관리할 수 있습니다. 로컬 설치를 피할 수 있고, 인증된 액세스와 영구 스토리지를 제공하므로 모바일 친화적인 완전한 관리 도구입니다.

Windows PowerShell은 Azure를 관리하는 데 흔히 사용되는 scripting 및 automation 환경(대개 Az PowerShell module 사용)입니다. 그러나 Windows(또는 최소한 호환되는 PowerShell runtime) 환경을 전제로 합니다. iPhone은 표준 Windows PowerShell 실행 환경을 네이티브로 제공하지 않으므로, 휴대폰에서 설정을 관리하기 위한 완전한 솔루션이 아닙니다.

Azure Storage Explorer는 Azure Storage 리소스(blobs, files, queues, tables)를 관리하도록 설계된 클라이언트 애플리케이션입니다. App Service web app 설정을 구성하거나 관리하기 위한 용도가 아닙니다. 또한 모바일 우선 관리 옵션이 아니라 데스크톱 도구이므로 이 요구 사항에 적합하지 않습니다.

문제 분석

핵심 개념: 이 문제는 Azure 관리 도구와 다양한 디바이스에서 Azure 리소스(Azure App Service Web App)를 관리하는 방법을 평가합니다. AZ-900에서는 주요 관리 평면인 Azure portal(웹 UI), Azure Cloud Shell(브라우저 기반 shell), 그리고 일반적으로 적절한 실행 환경이 필요한 command-line 도구(Azure CLI/PowerShell)를 인지해야 합니다. 정답이 맞는 이유: iPhone에서 web app의 설정을 관리하는 가장 실용적이고 완전히 지원되는 방법은 다음과 같습니다. 1) Azure portal (B): 모바일 브라우저에서 접근 가능한 웹 기반 인터페이스입니다. application settings, connection strings, deployment slots, scaling, monitoring 등 App Service 구성을 확인하고 수정할 수 있습니다. 2) Azure Cloud Shell (C): Cloud Shell은 브라우저에서 실행되며 Azure에서 호스팅되는 인증된 shell 환경을 제공합니다. 브라우저 기반이므로 로컬 도구를 설치하지 않고 iPhone에서 사용할 수 있습니다. Cloud Shell에서 Azure CLI 또는 Azure PowerShell 명령을 실행하여 web app을 관리할 수 있습니다. 주요 기능 및 모범 사례: - Azure portal은 App Service 구성에 대한 가이드형 경험, 유효성 검사, 리소스 blade를 제공합니다. Azure Well-Architected의 운영 우수성(Operational Excellence)에 맞게 day-2 운영(구성, 진단, RBAC를 통한 액세스 제어)을 단순화합니다. - Azure Cloud Shell은 관리형 환경(Azure CLI 및 PowerShell 사용 가능)과 Azure Files share를 통한 영구 스토리지를 제공하여, 로컬 설정 없이 반복 가능한 운영 작업과 스크립트를 수행할 수 있습니다. 흔한 오해: - Azure CLI (A)와 Windows PowerShell (D)은 관리 도구이지만, 일반적으로 설치와 호환되는 로컬 runtime이 필요합니다. iPhone은 이러한 도구를 네이티브로 설치하고 실행하기에 일반적인 환경이 아니므로, 이 문맥에서는 완전한 솔루션으로 간주되지 않습니다. - Azure Storage Explorer (E)는 storage account(blobs, files, queues, tables)를 관리하는 도구이며 App Service web app 설정을 관리하는 데 사용되지 않습니다. 시험 팁: “휴대폰/모바일 디바이스에서 관리” 유형의 문제에서는 브라우저 기반 도구인 Azure portal과 Cloud Shell을 우선 고려하십시오. 문제가 “로컬 설치 없음”을 시사한다면 Cloud Shell이 최적의 선택인 경우가 많습니다. 또한 도구를 리소스 유형에 매핑하십시오: Storage Explorer는 storage용이며 App Service 구성용이 아닙니다.

2
문제 2

HOTSPOT - 다음 각 설명에 대해, 설명이 참이면 Yes를 선택합니다. 그렇지 않으면 No를 선택합니다. 참고: 각 정답 선택은 1점입니다. 핫 영역:

파트 1:

Azure Advisor는 Azure Active Directory(Azure AD) 환경의 보안을 개선하는 방법에 대한 권장 사항을 제공합니다.

Azure Advisor는 Azure Active Directory(Azure AD) / Microsoft Entra ID 환경의 보안을 개선하기 위한 권장 사항을 주로 제공하지 않습니다. Advisor의 “Security” 권장 사항은 Azure 리소스 및 구성(예: 보안 구성 활성화, 노출 감소, 워크로드의 보안 상태 개선)에 초점을 맞춥니다. 로그인 위험 정책 개선, MFA 적용 범위, conditional access 상태, 기타 디렉터리 강화 조치와 같은 ID 관련 보안 권장 사항은 일반적으로 Identity Secure Score 및 관련 ID 보호/거버넌스 기능과 같은 Microsoft Entra ID 기능을 통해 제공됩니다. 시험 관점에서, 문장이 명시적으로 “Azure AD environment”에 관한 것이라면 Azure Advisor가 가장 적합한 도구가 아닙니다. Advisor가 더 광범위한 보안 가이드와 통합될 수는 있지만, Entra ID 보안 상태 권장 사항을 제공하는 주요 도구는 아닙니다. 따라서 해당 문장은 거짓입니다.

파트 2:

Azure Advisor는 Azure virtual machines를 실행하는 비용을 줄이는 방법에 대한 권장 사항을 제공합니다.

Azure Advisor는 Azure virtual machines를 실행하는 비용을 줄이기 위한 권장 사항을 실제로 제공합니다. 이는 Advisor의 핵심 범주 중 하나인 Cost입니다. Advisor는 VM utilization과 configuration/usage patterns를 분석하고, 활용도가 낮은 VM의 resizing(right-sizing), 유휴 VM의 shut down 또는 delete, 적절한 경우 reserved instances/savings plans 구매, 지출을 줄이기 위한 resource selection 최적화와 같은 조치를 권장할 수 있습니다. AZ-900에서는 비용 최적화 가이던스가 Azure Advisor의 대표적인 특징이며, reliability, performance, security, operational excellence와 함께 제공된다는 점을 기억하세요. 비용 분석, budgeting, chargeback/showback을 위한 주요 서비스는 Azure Cost Management + Billing이지만, Advisor는 telemetry를 처방형(prescriptive) 비용 절감 권장 사항으로 전환해 주는 서비스입니다. 따라서 해당 진술은 참입니다.

파트 3:

Azure Advisor는 Azure virtual machines에서 네트워크 설정을 구성하는 방법에 대한 권장 사항을 제공합니다.

Azure Advisor는 Azure virtual machines에서 네트워크 설정을 구성하는 방법(예: 상세 NIC/IP 구성, subnetting 전략, NSG 규칙 설계, routing 또는 DNS 설정)에 대한 일반적인 권장 사항을 제공하기 위한 용도가 아닙니다. 이러한 항목은 일반적으로 Azure networking 모범 사례를 사용해 설계하고, Azure Network Watcher, NSG flow logs, Connection troubleshoot 및 아키텍처 가이던스와 같은 도구로 검증합니다. Advisor는 때때로 네트워킹과 관련된 일부 VM 기능(예: 지원되는 VM size에서 throughput/latency를 개선하기 위해 accelerated networking을 활성화하는 것, 또는 기타 성능/신뢰성 제안)을 권장할 수 있습니다. 그러나 이는 VM 네트워크 설정을 전반적으로 구성하는 방법에 대한 권장 사항을 제공하는 것과는 다릅니다. AZ-900 문구에서 “Azure virtual machines에서 네트워크 설정을 구성”은 상세 네트워크 구성 가이던스를 의미하며, 이는 Advisor의 역할이 아닙니다. 따라서 해당 진술은 거짓입니다.

3
문제 3
(2개 선택)

귀사는 Azure에 데이터를 업로드할 수백만 개의 센서를 배포할 계획입니다. 계획된 솔루션을 지원하기 위해 생성해야 하는 Azure 리소스를 식별해야 합니다. 식별해야 하는 두 가지 Azure 리소스는 무엇입니까? 각 정답은 솔루션의 일부를 제시합니다. 참고: 각 정답 선택은 1점입니다.

Azure Data Lake는 수백만 개의 센서가 생성하는 매우 큰 양의 텔레메트리를 저장하기에 적절한 리소스입니다. 이는 대규모 확장 가능한 스토리지 및 analytics 워크로드를 위해 구축되었으며, 조직이 원시 IoT 데이터와 처리된 IoT 데이터를 후속 분석을 위해 보관할 수 있게 합니다. IoT 아키텍처에서 디바이스가 Data Lake에 직접 연결되지는 않지만, 업로드된 센서 데이터를 위한 핵심 지원 리소스입니다. 따라서 문제가 배포를 지원하기 위해 어떤 리소스를 생성해야 하는지 묻는 경우, 전체 솔루션의 유효한 구성 요소가 됩니다.

Azure Queue storage는 애플리케이션 구성 요소를 분리하고 비동기 처리를 지원하는 데 사용되는 범용 message queue입니다. 일부 아키텍처에서는 유용할 수 있지만, 수백만 개의 센서를 연결하거나 업로드된 텔레메트리 데이터를 저장하기 위해 필요한 기본 Azure 리소스는 아닙니다. 문제는 계획된 IoT 솔루션을 지원하기 위해 반드시 생성해야 하는 리소스를 묻고 있으며, Queue storage는 핵심 요소라기보다 선택 사항입니다. AZ-900에서는 전용 IoT 수집 서비스와 확장 가능한 데이터 저장소가 있는 경우, generic queue는 보통 최선의 답이 아닙니다.

Azure File Storage는 공유 파일 액세스가 필요한 애플리케이션과 사용자를 위해 SMB 또는 NFS를 통해 관리형 file share를 제공합니다. 이는 전통적인 파일 기반 워크로드, lift-and-shift 시나리오, 공유 스토리지를 위한 것이며, analytics에 적합한 방식으로 대용량 IoT 텔레메트리를 수집하거나 저장하기 위한 것은 아닙니다. 디바이스 연결, 메시지 수집, 또는 센서 데이터 파이프라인에 대한 특화된 지원을 제공하지 않습니다. 따라서 이 시나리오에 적절한 선택이 아닙니다.

Azure IoT Hub는 대규모 IoT 디바이스를 안전하게 연결하고, 인증하고, 관리하기 위한 전용 Azure 서비스입니다. 이는 device-to-cloud 텔레메트리 수집, cloud-to-device 메시징, 디바이스별 identity, 그리고 처리 및 스토리지를 위한 downstream 서비스와의 통합을 지원합니다. 수백만 개의 센서가 데이터를 업로드하는 시나리오에서 IoT Hub는 고규모 IoT 통신을 위해 특별히 설계되었기 때문에 대표적인 Azure 서비스입니다. 따라서 계획된 솔루션에서 필수적인 리소스입니다.

Azure Notification Hubs는 iOS 및 Android와 같은 플랫폼 전반에서 모바일 앱 사용자에게 push notification을 보내기 위해 설계되었습니다. 그 목적은 사용자 참여와 브로드캐스트 메시징이지, 센서로부터 텔레메트리를 수집하거나 IoT 디바이스를 관리하는 것이 아닙니다. 이는 device-to-cloud 텔레메트리 파이프라인, 디바이스별 IoT identity, 또는 대규모 센서 데이터 스토리지를 제공하지 않습니다. 따라서 이 솔루션의 핵심 요구 사항과는 관련이 없습니다.

문제 분석

핵심 개념: 이 문제는 대규모 IoT 솔루션에서 사용되는 Azure 서비스를 식별할 수 있는지를 평가합니다. 하나의 서비스는 디바이스를 안전하게 연결하고 텔레메트리를 수집하는 용도이고, 다른 하나의 서비스는 나중에 처리 및 분석할 수 있도록 업로드된 대량의 데이터를 저장하는 용도입니다. 수백만 개의 센서가 있는 경우, Azure IoT Hub는 이러한 목적에 맞게 설계된 수집 및 디바이스 관리 서비스이며, Azure Data Lake는 수집된 데이터를 위한 확장 가능한 스토리지 계층입니다. 정답인 이유: Azure IoT Hub는 IoT 시나리오를 위해 특별히 설계되었으며, 안전한 device-to-cloud 통신, 디바이스별 identity, 대규모 텔레메트리 수집을 지원합니다. Azure Data Lake는 센서 데이터가 업로드된 후 이를 저장하기 위한 대규모 확장 가능한 스토리지를 제공하므로, 대용량 텔레메트리 스트림을 보관하고 분석하는 데 적합합니다. 이 두 서비스는 함께 계획된 솔루션의 수집 및 스토리지 요구 사항을 모두 충족합니다. 주요 기능: IoT Hub는 양방향 통신, device provisioning, authentication, 그리고 수백만 개의 디바이스를 위한 message routing을 지원합니다. Azure Data Lake는 hierarchical namespace, big data analytics 통합, 그리고 매우 큰 규모의 structured 및 unstructured 텔레메트리 저장을 지원합니다. 이 조합은 Azure IoT 아키텍처에서 일반적이며, 데이터가 먼저 수집된 후 분석을 위해 저장됩니다. 흔한 오해: Azure Queue storage는 범용 메시징 서비스이지만, IoT 규모에서 디바이스 연결을 지원하기 위해 반드시 생성해야 하는 기본 서비스는 아니며, 텔레메트리 데이터의 대표적인 저장 대상도 아닙니다. Azure File Storage는 file share용이고, Notification Hubs는 모바일 push notification용입니다. 시험에서는 일반적으로 선택적 buffering 구성 요소가 아니라, 전용 IoT 서비스와 확장 가능한 데이터 스토리지 서비스를 기대합니다. 시험 팁: AZ-900에서 센서나 디바이스가 대규모로 텔레메트리를 전송하는 상황이 보이면 먼저 Azure IoT Hub를 떠올리세요. 문제가 솔루션을 지원하기 위해 두 개의 리소스를 묻는다면, 두 번째는 종종 generic queue가 아니라 Azure Data Lake와 같은 스토리지 또는 analytics 서비스입니다. 핵심 비즈니스 요구 사항에 집중하세요: 디바이스를 연결하고 업로드된 데이터를 저장하는 것입니다.

4
문제 4

참고: 이 문제는 동일한 시나리오를 제시하는 일련의 문제 중 일부입니다. 이 시리즈의 각 문제에는 제시된 목표를 충족할 수도 있는 고유한 솔루션이 포함되어 있습니다. 일부 문제 세트에는 정답이 둘 이상 있을 수 있으며, 다른 문제 세트에는 정답이 없을 수도 있습니다. 이 섹션의 문제에 답한 후에는 해당 문제로 돌아갈 수 없습니다. 따라서 이러한 문제는 검토 화면에 표시되지 않습니다. 회사에는 다음과 같은 미사용 리소스가 포함된 Azure 구독이 있습니다. ✑ Azure Active Directory (Azure AD)의 사용자 계정 20개 ✑ Azure AD의 그룹 5개 ✑ 공용 IP 주소 10개 ✑ 네트워크 인터페이스 10개 회사에서 Azure 비용을 줄여야 합니다. 솔루션: 미사용 네트워크 인터페이스를 제거합니다. 이것이 목표를 충족하나요?

"예"라고 답하는 것은 미사용 network interfaces가 지속적인 요금을 발생시킨다고 가정하는데, 이는 Azure에서 일반적으로 사실이 아닙니다. NIC 자체는 보통 반복 비용이 발생하지 않으며, 요금은 compute, public IPs, NAT gateways, 또는 data transfer 같은 연관 서비스에서 발생합니다. 따라서 연결되지 않은 NIC를 삭제해도 구독에서 의미 있는 청구 항목이 제거되지 않습니다. 결과적으로 이 조치는 비용을 안정적으로 줄이지 못합니다.

Azure의 network interfaces는 일반적으로 독립적인 리소스로 과금되지 않으며, compute 리소스를 virtual network에 연결하는 데 사용되는 control-plane 객체입니다. NIC가 미사용/미연결 상태라면, 보통 삭제로 제거할 수 있는 반복 청구 비용이 없습니다. Azure 비용은 더 일반적으로 실행 중인 VMs, managed disks, gateways, 또는 할당된 public IPs(특히 Standard SKU)와 같은 과금 대상 리소스를 제거함으로써 줄일 수 있습니다. 따라서 미사용 NIC를 제거하는 것은 Azure 비용을 줄인다는 목표를 충족하지 않습니다.

문제 분석

핵심 개념: 이 문제는 어떤 Azure 리소스가 지속적인 요금을 발생시키는지, 그리고 어떤 리소스가 무료(또는 사용 시에만 요금이 발생)인지 테스트하여, 실제로 Azure 비용을 줄이는 조치를 식별할 수 있는지를 확인합니다. 정답이 맞는 이유: 미사용 network interface (NIC)를 제거하는 것은 일반적으로 Azure 비용을 줄이지 못합니다. NIC 자체에는 보통 독립적인 시간당 요금이 없기 때문입니다. NIC는 논리적 네트워킹 리소스로, 연결된 과금 대상 서비스(예: VM compute 요금, public IP 요금, NAT gateway 요금, 데이터 처리/egress)를 통해 간접적으로 과금됩니다. NIC가 미사용(실행 중인 VM 또는 기타 과금 대상 구성 요소에 연결되지 않음)인 경우, 이를 삭제해도 반복적으로 청구되는 비용 항목이 제거되지 않습니다. 따라서 이 조치는 Azure 비용을 줄인다는 목표를 충족하지 않습니다. 주요 기능/구성: - Azure Network Interface (NIC): 일반적으로 자체적으로는 직접 비용이 없습니다. - 비용은 일반적으로 다음에 의해 발생합니다. - 할당된 public IP addresses(특히 Standard SKU). - 실행 중인 compute (VMs), load balancers, NAT Gateway, VPN/ExpressRoute, 및 data egress. - managed disks 및 기타 storage 리소스. - Azure AD users/groups: 일반적으로 사용하지 않는 accounts/groups를 삭제한다고 해서 비용이 줄어드는 방식으로 객체당 과금되지 않습니다(라이선싱이 비용의 핵심 요인입니다). 흔한 오해: - 리소스 그룹에 존재한다는 이유만으로 모든 리소스가 요금을 발생시킨다고 가정하는 것. - “unused”와 “unattached”를 혼동하는 것: NIC는 연결되지 않은 상태로 존재할 수 있으며, 그 자체로 비용이 들지 않을 수 있습니다. - Azure AD 객체를 삭제하면 비용이 줄어든다고 믿는 것: 대부분의 경우 비용은 users/groups 수가 아니라 라이선스(예: Entra ID P1/P2)에 의해 결정됩니다. 시험 팁: - 반복 과금이 발생하는 것으로 알려진 리소스에 집중하세요: compute, storage, public IPs (Standard), gateways, 및 data transfer. - 기억하세요: 많은 control-plane 객체(NICs, VNets, NSGs, route tables)는 일반적으로 직접 비용이 없습니다. - ID 영역에서 비용 절감은 보통 users/groups 삭제가 아니라 라이선스 제거/다운사이징으로 이루어집니다.

5
문제 5

참고: 이 질문은 동일한 시나리오를 제시하는 일련의 질문 중 일부입니다. 이 시리즈의 각 질문에는 제시된 목표를 충족할 수도 있는 고유한 솔루션이 포함되어 있습니다. 일부 질문 세트에는 정답이 둘 이상 있을 수 있으며, 다른 세트에는 정답이 없을 수도 있습니다. 이 섹션의 질문에 답한 후에는 해당 질문으로 돌아갈 수 없습니다. 따라서 이러한 질문은 검토 화면에 표시되지 않습니다. 여러 Azure virtual machines를 배포할 계획입니다. 단일 data center가 장애가 발생하더라도 virtual machines에서 실행 중인 서비스가 사용 가능하도록 보장해야 합니다. 솔루션: virtual machines를 두 개 이상의 resource groups에 배포합니다. 이것이 목표를 충족하나요?

예는 오답인 이유는 resource groups가 별도의 datacenters, zones 또는 fault domains에 매핑되지 않기 때문입니다. 이는 순수하게 관리용 구성 요소입니다. 서로 다른 resource groups에 있는 VM도 동일한 availability zone 또는 동일한 기본 datacenter에 배포될 수 있으므로, datacenter 장애가 발생하면 모든 인스턴스가 중단될 수 있습니다. datacenter 장애에 대한 high availability에는 zonal redundancy(Availability Zones)와 일반적으로 load-balancing 또는 failover 메커니즘이 필요하며, 단순한 조직적 분리만으로는 충분하지 않습니다.

아니요가 정답인 이유는 여러 resource groups에 VM을 배포해도 인프라 또는 datacenter 수준에서 어떤 장애 격리도 제공하지 않기 때문입니다. resource groups는 리소스를 구성하고, RBAC 및 정책을 적용하며, 수명 주기 작업을 관리하는 데 사용되는 논리적 컨테이너이지만, 물리적 배치를 제어하지 않습니다. 단일 datacenter 장애를 견디는 요구 사항을 충족하려면 인스턴스가 서로 다른 장애 격리 위치에서 실행되도록 Availability Zones(또는 multi-region 설계)를 사용해야 합니다.

문제 분석

핵심 개념: 이 질문은 virtual machines에 대한 Azure 복원력(resiliency) 구성 요소를 테스트합니다. 구체적으로 단일 datacenter(availability zone) 장애에 대한 보호를 제공하는 것이 무엇인지, 그리고 단지 조직화 경계(resource groups)일 뿐인 것이 무엇인지 구분하는지 확인합니다. 정답인 이유: VM을 두 개 이상의 resource groups에 배포해도 VM이 물리적으로 실행되는 위치는 바뀌지 않습니다. resource group은 관리, RBAC, 그리고 수명 주기(lifecycle) 작업을 위한 논리적 컨테이너이며, datacenter 간 장애 격리를 제공하지 않습니다. 단일 datacenter가 장애가 발생해도 가용성을 유지하려면 VM(또는 워크로드)을 Availability Zones(존 배포) 또는 regions(페어드 regions)와 같은 장애 격리 위치에 걸쳐 배포하고, 적절한 아키텍처(예: zone-redundant load balancing, multi-region failover)를 사용해야 합니다. 주요 기능 / 구성: - Availability Zones: 동일 region 내의 서로 다른 zones에 VM을 배치하여 datacenter/zone 장애를 견딜 수 있습니다. - Availability Sets: datacenter 내에서 rack/power/network 장애( fault/update domains )로부터 보호하지만, 전체 datacenter 장애는 보호하지 못합니다. - Load Balancer (Standard) / Application Gateway: zonal VM 인스턴스 전반에 트래픽을 분산하며, zone-redundant로 구성할 수 있습니다. - Multi-region 패턴: Azure Traffic Manager / Front Door + regional 배포를 통해 regional disaster recovery를 구현합니다. 흔한 오해: - resource groups가 high availability 또는 물리적 분리를 제공한다고 가정하는 것; 그렇지 않습니다. - Availability Sets와 Availability Zones를 혼동하는 것; availability sets는 전체 datacenter 장애를 커버하지 않습니다. - “resource groups를 분리”하면 “datacenters를 분리”하는 것이라고 믿는 것; 물리적 복원력은 zonal 또는 regional 설계가 필요합니다. 시험 팁: - resource groups = 관리 경계이며, 복원력이 아닙니다. - Azure에서 “단일 datacenter 장애”는 Availability Zones를 떠올리세요. - Availability Sets는 호스트/rack 유지보수 및 국지적 장애에 도움이 되지만, zone 전체 장애에는 해당되지 않습니다. - zone 장애 시에도 서비스에 도달 가능하도록 zonal 배포를 load balancer와 함께 구성하세요.

이동 중에도 모든 문제를 풀고 싶으신가요?

Cloud Pass를 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.

6
문제 6

참고: 이 질문은 동일한 시나리오를 제시하는 일련의 질문 중 일부입니다. 이 시리즈의 각 질문에는 제시된 목표를 충족할 수도 있는 고유한 솔루션이 포함되어 있습니다. 일부 질문 세트에는 정답이 둘 이상 있을 수 있으며, 다른 세트에는 정답이 없을 수도 있습니다. 이 섹션의 질문에 답한 후에는 해당 질문으로 돌아갈 수 없습니다. 따라서 이러한 질문은 검토 화면에 표시되지 않습니다. Azure 환경에는 여러 Azure virtual machine이 포함되어 있습니다. VM1이라는 virtual machine이 Internet에서 HTTP를 통해 액세스 가능하도록 해야 합니다. 솔루션: Azure Traffic Manager profile을 수정합니다. 이것이 목표를 충족합니까?

"예"라고 답하는 것은 Traffic Manager가 VM1을 HTTP로 도달 가능하게 만들 수 있음을 의미하지만, Traffic Manager는 인바운드 연결이나 포트 노출을 처리하지 않습니다. public IP, Azure Load Balancer, 또는 Application Gateway를 대체하지 않으며, 인바운드 TCP/80을 제어하는 NSG 규칙도 변경하지 않습니다. 기껏해야 DNS를 통해 이미 public인 endpoint로 사용자를 유도할 수 있을 뿐이며, 이는 VM1이 액세스 가능해지는 것을 보장하기에 충분하지 않습니다. 따라서 이 솔루션은 제시된 목표를 충족하지 않습니다.

Traffic Manager는 클라이언트를 endpoint로 가리키는 DNS 응답만 반환할 뿐, VM으로의 네트워크 경로를 생성하거나 수정하지 않습니다. Internet 액세스에 필요한 TCP/80을 열거나, public IP를 할당하거나, 인바운드 NAT/부하 분산 규칙을 구성할 수 없습니다. VM1이 endpoint로 등록되더라도 Traffic Manager가 유용하려면 VM1이 이미 HTTP에 대해 public으로 도달 가능해야 합니다. 따라서 Traffic Manager profile만 수정하는 것으로는 VM1이 Internet에서 HTTP로 액세스 가능하다는 것을 보장할 수 없습니다.

문제 분석

핵심 개념: 이 질문은 Azure virtual machine을 public Internet에 HTTP로 노출하는 방법과, 특정 VM에 대한 인바운드 연결을 실제로 제어하는 Azure 네트워킹 서비스가 무엇인지 테스트합니다. 정답이 맞는 이유: Azure Traffic Manager는 DNS 기반의 글로벌 트래픽 분산 서비스입니다. 서로 다른 public endpoint(예: 서로 다른 region)로 클라이언트를 유도하기 위해 서로 다른 DNS 응답을 반환할 수 있지만, 포트를 열거나, 인바운드 NAT를 수행하거나, Internet에서 VM의 도달 가능성을 변경하지는 않습니다. VM1을 HTTP로 액세스 가능하게 하려면 VM1에 public 진입점(public IP 또는 public load balancer)이 있고, NSG 규칙(및 OS firewall)에서 인바운드 TCP/80이 허용되어야 합니다. 따라서 Traffic Manager profile만 수정하는 것은 목표를 충족하지 않습니다. 주요 기능 / 구성: - Azure Traffic Manager: DNS 기반 라우팅(Priority/Weighted/Performance/Geographic/Multivalue/Subnet), endpoint 모니터링, DNS 응답만 반환. - VM을 HTTP로 노출하는 데 필요한 사항: Public IP(또는 Public Load Balancer/Application Gateway), TCP/80에 대한 인바운드 규칙, NSG 인바운드 허용, 그리고 OS firewall/웹 서버가 port 80에서 수신 중이어야 함. - 일반적인 패턴: 인바운드 NAT/부하 분산 규칙이 있는 Public Load Balancer; HTTP/HTTPS용 Application Gateway(L7); 글로벌 HTTP(S) 진입점용 Azure Front Door. 흔한 오해: - Traffic Manager가 서비스를 Internet에 “게시”한다고 가정하는 것; 실제로는 DNS 해석에만 영향을 줍니다. - 인바운드 연결을 실제로 수락하는 Layer 4/7 load balancer(Azure Load Balancer/Application Gateway/Front Door)와 Traffic Manager를 혼동하는 것. - NSG 및 public IP/LB 구성이 TCP/80이 VM에 도달할 수 있는지 여부를 결정한다는 점을 놓치는 것. 시험 팁: - Traffic Manager = DNS 기반 라우팅이며, data-plane proxy도 아니고 firewall/NAT도 아닙니다. - VM을 Internet에서 도달 가능하게 하려면: public endpoint + NSG 허용 + 서비스가 수신 중이어야 합니다. - HTTP 관련 시나리오에서는 Application Gateway 또는 Front Door를 고려하고, TCP/UDP에는 Azure Load Balancer를 고려하세요.

7
문제 7

참고: 이 문제는 동일한 시나리오를 제시하는 일련의 문제 중 일부입니다. 시리즈의 각 문제에는 제시된 목표를 충족할 수도 있는 고유한 솔루션이 포함되어 있습니다. 일부 문제 세트에는 정답이 둘 이상 있을 수 있으며, 다른 문제 세트에는 정답이 없을 수도 있습니다. 이 섹션에서 문제에 답한 후에는 해당 문제로 돌아갈 수 없습니다. 따라서 이러한 문제는 검토 화면에 표시되지 않습니다. Azure administrator가 Azure resources를 생성하는 PowerShell script를 실행할 계획입니다. script를 실행하는 데 사용할 computer configuration을 권장해야 합니다. 솔루션: macOS를 실행하고 PowerShell Core 6.0이 설치된 컴퓨터에서 script를 실행합니다. 이것이 목표를 충족합니까?

예. PowerShell Core 6.0은 macOS에서 지원되며, Azure PowerShell은 해당 환경에서 Azure resources를 생성하고 관리하는 데 사용할 수 있습니다. Az module을 설치하면 관리자는 Azure에 인증하고 Windows 또는 Linux에서와 마찬가지로 필요한 script를 실행할 수 있습니다. 지원되는 cross-platform tooling을 사용하는 경우 operating system은 Azure resource deployment를 방해하지 않습니다.

아니요는 올바르지 않습니다. 제안된 구성은 Azure PowerShell에 대해 유효하기 때문입니다. Azure PowerShell은 Windows로 제한되지 않으며, PowerShell Core는 cross-platform administration을 지원하기 위해 특별히 만들어졌습니다. PowerShell Core 6.0이 설치된 macOS device는 필요한 Azure modules, network access, permissions가 제공된다면 Azure scripts를 성공적으로 실행할 수 있습니다.

문제 분석

핵심 개념: 이 문제는 Azure support plans와 어떤 communication channels(phone/email)을 사용할 수 있는지에 대한 지식을 평가합니다. AZ-900에서는 Basic, Developer, Standard, Professional Direct, Premier/Unified (enterprise) support를 구분하고, 이를 비즈니스 요구 사항에 매핑할 수 있어야 합니다. 정답인 이유: Standard support plan은 technical support requests에 대해 phone 및 email을 통해 Microsoft support engineers에 접근할 수 있으므로 요구 사항을 충족합니다. 회사 정책은 support engineers에 phone 또는 email로 접근할 수 있는 옵션을 명시적으로 요구하며, Standard는 그 기능을 제공합니다(심각도에 따라 정의된 response times도 함께 제공). 따라서 Standard를 권장하는 것은 제시된 목표를 충족합니다. 주요 기능 / 알아둘 사항: - Basic support(모든 Azure subscription에 포함)는 billing 및 subscription support를 제공하지만 technical support engineer access는 제공하지 않습니다. - Developer support는 business hours 동안 email을 통한 technical support를 제공하며(비프로덕션/dev workloads용으로 의도됨). - Standard support는 production workloads를 위한 technical support를 제공하며, Developer보다 더 빠른 response times와 함께 phone 및 email access를 포함합니다. - Professional Direct는 proactive guidance(예: advisory services)와 일반적으로 더 빠르고/더 포괄적인 support experience를 추가합니다. - Premier/Unified는 가장 포괄적인 coverage를 제공하는 enterprise agreements입니다. Azure Well-Architected Framework 관점에서(Operational Excellence 및 Reliability), engineer access가 있는 support plan을 갖추는 것은 incident response readiness와 operational supportability의 일부입니다. Standard는 조직이 production environments에 대해 일반적으로 선택하는 최소 plan인 경우가 많습니다. 흔한 오해: 자주 있는 혼동 중 하나는 Basic이 “included”되어 있으므로 technical support도 포함한다고 생각하는 것입니다. Basic은 일반적으로 billing/subscription issues와 self-help resources를 다루며, technical issues에 대해 support engineers에 직접 접근하는 기능은 제공하지 않습니다. 또 다른 오해는 Developer가 항상 충분하다고 생각하는 것입니다. email 기반 technical support를 포함할 수는 있지만, dev/test용으로 포지셔닝되어 있으며 시간 제한과 더 느린 response가 있습니다. 시험 팁: - 요구 사항에 “phone support”가 언급되면 Developer는 충분하지 않을 수 있으므로 Standard(또는 그 이상)가 안전한 선택입니다. - 요구 사항이 단지 “support engineers에 대한 email access”뿐이라면 Developer도 해당될 수 있지만, production인지 dev/test인지에 대한 표현을 주의 깊게 읽으세요. - AZ-900에서는 상위 수준의 차이점에 집중하세요: Basic(no technical), Developer(email/business hours), Standard(phone+email, production), Pro Direct(proactive).

8
문제 8

참고: 이 질문은 동일한 시나리오를 제시하는 일련의 질문 중 일부입니다. 이 시리즈의 각 질문에는 명시된 목표를 충족할 수 있는 고유한 솔루션이 포함되어 있습니다. 일부 질문 세트에는 정답이 두 개 이상 있을 수 있으며, 다른 세트에는 정답이 없을 수도 있습니다. 이 섹션의 질문에 답한 후에는 해당 질문으로 돌아갈 수 없습니다. 따라서 이러한 질문은 검토 화면에 표시되지 않습니다. Azure 환경에는 여러 Azure virtual machine이 포함되어 있습니다. Internet에서 HTTP를 통해 VM1이라는 virtual machine에 액세스할 수 있도록 해야 합니다. 솔루션: network security group (NSG)을 수정합니다. 이것이 목표를 충족합니까?

예. NSG는 TCP port 80의 inbound HTTP 트래픽을 포함하여 virtual machine 또는 subnet에 대한 network 트래픽을 허용하거나 거부하는 데 사용되는 Azure 리소스입니다. VM1에 public IP address 또는 public load balancer와 같이 이미 Internet로부터의 경로가 있다면, port 80을 허용하도록 NSG 규칙을 추가하거나 수정하면 HTTP 액세스가 가능해집니다. AZ-900 시험 맥락에서는 NSG가 Azure VM에 대한 web 트래픽을 허용하는 표준 제어 수단이므로 이것은 유효한 해결책으로 간주됩니다.

아니오가 틀린 이유는 NSG가 HTTP 트래픽이 VM에 도달할 수 있는지를 제어하는 것과 직접적으로 관련이 있기 때문입니다. NSG 자체가 public IP address를 할당하거나 Internet 노출을 생성하지는 않지만, inbound port 80을 허용하도록 수정하는 것은 여전히 이러한 유형의 시험 시나리오에서 제시된 목표를 충족하는 올바른 조치입니다. 문제는 NSG를 수정하는 것이 목표를 충족하는지 묻고 있으며, NSG를 통해 HTTP를 허용하는 것이 바로 Azure가 해당 트래픽을 허용하는 방식입니다.

문제 분석

핵심 개념: Network Security Groups (NSG)는 allow 및 deny 규칙을 사용하여 Azure virtual machines와 subnets에 대한 inbound 및 outbound 트래픽을 제어합니다. 정답인 이유: VM1을 Internet에서 HTTP로 액세스 가능하게 하려면 TCP port 80을 허용하는 inbound 규칙이 필요하며, VM이 이미 public IP 또는 load balancer를 통해 Internet 도달성을 가지고 있다면 NSG를 수정하는 것은 이를 달성하는 유효한 방법입니다. 주요 기능: NSG는 NIC 또는 subnet에 연결할 수 있고, 우선순위에 따라 규칙을 평가하며, HTTP (80) 및 HTTPS (443)와 같은 web 트래픽을 허용하는 데 일반적으로 사용됩니다. 흔한 오해: NSG만으로는 public endpoint를 제공하지 않으며, VM에는 public IP address가 있거나 public load balancer 뒤에 있어야 합니다. 그러나 이러한 AZ-900 시나리오 문제에서는 트래픽 유형을 허용하는 것이 목표일 때 NSG를 변경하는 것만으로도 충분한 것으로 간주됩니다. 시험 팁: public IP와 같은 connectivity enabler와 NSG와 같은 traffic filter를 구분하세요. 문제에서 NSG를 수정하면 HTTP 액세스를 보장할 수 있는지 묻는다면, 일반적으로 정답은 yes입니다. NSG는 해당 inbound 트래픽을 허용하는 데 사용되는 메커니즘이기 때문입니다.

9
문제 9

HOTSPOT - 다음 각 진술에 대해, 진술이 참이면 Yes를 선택합니다. 그렇지 않으면 No를 선택합니다. 참고: 각 정답 선택은 1점입니다. Hot Area:

파트 1:

하이브리드 클라우드 모델을 구현하려면, 회사는 내부 네트워크를 보유해야 합니다.

예. 하이브리드 클라우드 모델은 조직이 퍼블릭 클라우드와 통합할 수 있는 어떤 형태의 내부 환경을 보유하고 있어야 합니다—일반적으로 온프레미스 네트워크 및/또는 프라이빗 클라우드 리소스입니다. 하이브리드의 정의적 특징은 두 환경(프라이빗/온프레미스 + 퍼블릭 클라우드)을 결합하고, 그 사이에 연결성과 조정이 존재한다는 점입니다. 실무에서는 보통 VPN 또는 ExpressRoute를 사용해 Azure에 연결된 내부 네트워크를 의미하며, 종종 공유 ID(Microsoft Entra ID), 모니터링, 거버넌스도 포함됩니다. “아니요”가 틀린 이유: 회사에 내부 네트워크나 프라이빗 환경이 전혀 없다면 하이브리드가 아니라 순수 퍼블릭 클라우드입니다. 하이브리드는 단순히 “클라우드 서비스를 사용한다”가 아니라, “온프레미스/프라이빗 리소스와 함께 클라우드 서비스를 사용한다”는 의미입니다.

파트 2:

회사는 hybrid cloud를 사용하여 내부 네트워크의 컴퓨팅 리소스를 확장할 수 있습니다.

예. hybrid cloud의 가장 일반적인 이점/사용 사례 중 하나는 public cloud 리소스를 활용하여 on-premises 컴퓨팅 용량을 확장하는 것입니다. 이는 종종 scaling out, cloud bursting, 또는 피크 수요, dev/test, batch jobs, 또는 disaster recovery를 위한 임시/탄력적 용량 추가로 설명됩니다. 예를 들어, 조직은 핵심 시스템을 on-premises에 유지하면서 수요가 증가할 때 Azure에서 추가 web front ends 또는 analytics workloads를 실행할 수 있습니다. “아니요”가 틀린 이유: hybrid cloud는 유연성과 탄력성 때문에 특히 가치가 있습니다—지연 시간, 규정 준수, 또는 legacy 이유로 특정 워크로드를 로컬에 유지하면서 Azure를 사용해 필요 시 compute/storage를 온디맨드로 추가할 수 있습니다. 이는 Well-Architected 원칙인 Performance Efficiency(탄력적 확장) 및 Cost Optimization(on-prem hardware의 과도한 프로비저닝 방지)을 지원합니다.

파트 3:

Public cloud 모델에서는 회사의 guest user만 cloud의 리소스에 액세스할 수 있습니다.

아니요. Public cloud 모델에서는 cloud 리소스에 대한 액세스가 회사의 “guest user”로 제한되지 않습니다. 액세스는 authentication 및 authorization 제어( Azure의 경우 일반적으로 Microsoft Entra ID identity, service principal/managed identity, Azure RBAC)와 network 제어(firewall, private endpoint, VNet) 및 기타 governance policy에 의해 결정됩니다. “예”가 틀린 이유: “Guest user”는 특정 identity 개념(B2B collaboration)이며 public cloud 액세스의 정의 규칙이 아닙니다. Public cloud 리소스는 내부 직원, 외부 파트너, 고객, 애플리케이션, automation account 등 권한이 부여된 어떤 identity라도 액세스할 수 있습니다. Public cloud는 provider가 소유한 infrastructure와 shared responsibility model을 의미하며, guest user만 리소스에 액세스할 수 있다는 제한을 의미하지 않습니다.

10
문제 10

참고: 이 문제는 동일한 시나리오를 제시하는 일련의 문제 중 일부입니다. 이 시리즈의 각 문제에는 제시된 목표를 충족할 수도 있는 고유한 솔루션이 포함되어 있습니다. 일부 문제 세트에는 정답이 둘 이상 있을 수 있으며, 다른 문제 세트에는 정답이 없을 수도 있습니다. 이 섹션에서 문제에 답한 후에는 해당 문제로 돌아갈 수 없습니다. 따라서 이러한 문제는 검토 화면에 표시되지 않습니다. 귀사는 모든 데이터와 리소스를 Azure로 마이그레이션할 계획입니다. 회사의 마이그레이션 계획에는 Azure에서 Platform as a Service (PaaS) 솔루션만 사용해야 한다고 명시되어 있습니다. 회사 마이그레이션 계획을 충족하는 Azure 환경을 배포해야 합니다. 솔루션: Azure virtual machines, Azure SQL databases 및 Azure Storage accounts를 생성합니다. 이것이 목표를 충족합니까?

Yes는 Azure virtual machines가 PaaS가 아니라는 점을 간과하므로 오답입니다. PaaS-only 요구 사항은 컴퓨팅이 VM 인스턴스가 아니라 managed platform services(예: App Service 또는 Functions)를 통해 제공되어야 함을 의미합니다. Azure SQL Database와 Azure Storage는 PaaS이지만, VMs가 포함되면 솔루션은 IaaS/PaaS 혼합 배포가 되어 규정을 준수하지 못합니다.

No가 정답인 이유는 솔루션에 Infrastructure as a Service (IaaS) 제공 항목인 Azure virtual machines가 포함되어 있기 때문입니다. Azure VMs를 사용하면 고객이 운영 체제 관리, 패치 및 VM 수준 구성을 책임져야 하며, 이는 엄격한 “PaaS-only” 마이그레이션 계획과 모순됩니다. Azure SQL Database와 Azure Storage accounts는 PaaS 서비스이지만, IaaS 구성 요소가 하나라도 존재하면 전체 환경은 명시된 요구 사항을 충족하지 않습니다.

문제 분석

핵심 개념: 이 문제는 Azure Platform as a Service (PaaS) 제공 항목을 Infrastructure as a Service (IaaS)와 구분하고, 제안된 배포가 “PaaS만” 마이그레이션 요구 사항을 준수하는지 판단하는 능력을 테스트합니다. 정답인 이유: 제안된 솔루션에는 IaaS 컴퓨팅 서비스인 Azure virtual machines가 포함되어 있습니다. “PaaS만” 요구 사항은 virtual machine 인스턴스(OS 패치, VM 크기 조정, VM 가용성 구성 요소)를 관리하는 것을 피하고, 대신 관리형 플랫폼 서비스(예: Azure App Service, Azure SQL Database, Azure Functions, Azure Container Apps)를 사용해야 함을 의미합니다. Azure SQL Database와 Azure Storage accounts는 PaaS 서비스이지만, Azure VMs가 포함되면 명시된 제약을 위반하므로 이 솔루션은 목표를 충족하지 않습니다. 주요 기능 / 구성: - Azure Virtual Machines: IaaS; 고객이 OS, 런타임 및 VM 수명 주기를 관리합니다. - Azure SQL Database: PaaS 데이터베이스; Microsoft가 OS 및 데이터베이스 엔진 인프라를 관리합니다. - Azure Storage accounts: 관리형 스토리지 서비스(PaaS); 서버 관리가 필요 없습니다. - VMs에 대한 PaaS-only 대안: Azure App Service, Azure Functions, Azure Container Apps, Azure Kubernetes Service(더 관리형으로 간주되기도 하지만 여전히 클러스터 관리가 수반됨), Azure Virtual Desktop은 PaaS-only가 아닙니다. 일반적인 오해: - 아키텍처에 IaaS 구성 요소가 포함되어 있어도 “일부 PaaS 서비스”를 사용하면 충분하다고 가정하는 것. - Azure VMs가 “Azure에 있다”는 이유로 PaaS라고 생각하는 것; OS와 VM 구성을 관리하므로 여전히 IaaS입니다. - “managed service”를 광범위하게 “PaaS-only”와 혼동하는 것; 많은 managed 제공 항목은 여전히 인프라 관리 책임이 필요합니다. 시험 팁: - 요구 사항이 “PaaS only”라면, Azure Virtual Machines가 포함되는 경우 일반적으로 답은 “No”입니다. - 서비스 모델을 빠르게 식별하세요: VMs = IaaS; App Service/Functions/SQL Database = PaaS. - 혼합 아키텍처(PaaS + IaaS)는 대부분의 구성 요소가 PaaS이더라도 엄격한 “PaaS-only” 제약을 충족하지 못합니다.

다른 모의고사

Practice Test #1

50 문제·45분·합격 700/1000

Practice Test #3

50 문제·45분·합격 700/1000

Practice Test #4

50 문제·45분·합격 700/1000

Practice Test #5

50 문제·45분·합격 700/1000

Practice Test #6

50 문제·45분·합격 700/1000

Practice Test #7

50 문제·45분·합격 700/1000

Practice Test #8

50 문제·45분·합격 700/1000

Practice Test #9

50 문제·45분·합격 700/1000
← 모든 Microsoft AZ-900 문제 보기

지금 학습 시작하기

Cloud Pass를 다운로드하고 모든 Microsoft AZ-900 기출 문제를 풀어보세요.

Get it on Google PlayDownload on the App Store
Cloud PassCloud Pass

IT 자격증 문제풀이 앱

Get it on Google PlayDownload on the App Store

자격증

AWSGCPMicrosoftCiscoCompTIADatabricks

법률

FAQ개인정보 처리방침서비스 약관

회사

문의하기계정 삭제

© Copyright 2026 Cloud Pass, All rights reserved.

이동 중에도 모든 문제를 풀고 싶으신가요?

앱 받기

Cloud Pass를 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.