모든 답안은 3개의 최고 AI 모델로 교차 검증하여 최고의 정확도를 보장합니다. 선택지별 상세 해설과 심층 문제 분석을 제공합니다.
GPT Pro
Claude Opus
Gemini Pro
선택지별 상세 해설
심층 문제 분석
3개 모델 합의 정확도
연습 문제
1
문제 1
귀사 개발자 팀은 매주 50개의 사용자 지정 가상 머신을 배포한 다음 제거할 계획입니다. 가상 머신 30대는 Windows
Server 2016을 실행하고, 가상 머신 20대는 Ubuntu Linux를 실행합니다.
가상 머신을 배포하고 제거하는 데 필요한 관리 노력을 최소화할 수 있는 Azure 서비스를 추천해야 합니다.
무엇을 추천해야 합니까?
Azure Reserved VM Instances는 지속적으로 실행되는 VM의 컴퓨팅 비용을 줄이기 위한(1년 또는 3년) 가격 약정입니다. 배포나 삭제를 단순화하지 않으며, 매주 생성되고 제거되는 워크로드에는 적합하지 않습니다. Reserved Instances는 안정적인 사용에 대한 비용 최적화를 다루며, 관리 노력이나 라이프사이클 자동화를 다루지 않습니다.
Azure virtual machine scale sets는 autoscaling 및 자동 인스턴스 복구를 통해 동일한 VM 집합을 배포하고 관리하는 데 도움이 되며, 일반적으로 상태 비저장 애플리케이션 계층에 사용됩니다. 대규모 플릿에 대한 노력을 줄일 수는 있지만, 혼합 구성에서 매주 자주 생성/삭제되는 사용자 지정 dev/test VM을 위해 주로 설계된 것은 아닙니다. 사용자 지정이 가능하더라도 이 시나리오에서는 DevTest Labs만큼 적합하지 않습니다.
Azure DevTest Labs는 팀이 환경을 빠르고 반복적으로 프로비저닝하고 손쉽게 정리해야 하는 dev/test 시나리오를 위해 설계되었습니다. Windows와 Linux를 지원하고, 표준화된 사용자 지정을 위한 formulas와 artifacts를 제공하며, 할당량 및 auto-shutdown 같은 policies를 포함하여 비용과 거버넌스 오버헤드를 줄입니다. 이는 매주 많은 VM을 배포하고 제거하는 데 필요한 관리 노력을 직접적으로 최소화합니다.
Microsoft Managed Desktop은 사용자에게 Windows 데스크톱을 제공하고 운영하기 위한 관리형 서비스(엔드포인트 관리, 보안, 업데이트)입니다. 개발/테스트를 위한 서버 VM 또는 Linux VM을 빠르게 프로비저닝하고 해제하는 용도가 아닙니다. 자동화된 VM 라이프사이클 관리보다는 최종 사용자 컴퓨팅 관리에 초점을 둡니다.
문제 분석
핵심 개념:
이 문제는 많은 사용자 지정 VM을 최소한의 관리 노력으로 빠르고 반복적으로 프로비저닝하고 해제(삭제)할 수 있도록 가장 잘 지원하는 Azure 서비스를 묻습니다. Azure에서는 일반적으로 셀프 서비스 환경, 재사용 가능한 템플릿, 자동화된 라이프사이클 관리를 위해 설계된 서비스를 의미합니다.
정답이 맞는 이유:
Azure DevTest Labs는 재사용 가능한 artifacts, formulas, policies를 사용하여 랩 환경(Windows 및 Linux VM 포함)을 빠르게 생성, 관리, 삭제하도록 특별히 설계되었습니다. 매주 50개의 사용자 지정 VM을 배포하고 제거하는 팀의 경우, DevTest Labs는 표준화된 VM 생성(사전 구성된 이미지 및 설정)과 손쉬운 정리(VM 또는 전체 랩 리소스 삭제)를 가능하게 하여 관리 오버헤드를 최소화합니다. 또한 Windows Server 2016과 Ubuntu를 모두 지원하므로 혼합 OS 요구 사항에도 부합합니다.
주요 기능 및 모범 사례:
DevTest Labs는 다음을 제공합니다.
- Formulas(사전 정의된 VM 구성)를 통해 일관된 “사용자 지정” VM을 반복적으로 배포
- Artifacts를 통해 프로비저닝 중 소프트웨어 자동 설치 및 구성 적용
- Policies(할당량, 허용 VM 크기, auto-shutdown)로 확산(sprawl)과 비용을 제어하여 Azure Well-Architected Framework의 비용 최적화 및 거버넌스에 부합
- 개발자를 위한 셀프 서비스 프로비저닝으로 중앙 IT 티켓 및 수동 작업 감소
이 조합은 “자주 배포하고 제거”하는 시나리오를 직접적으로 겨냥합니다.
흔한 오해:
VM Scale Sets는 많은 VM의 배포를 자동화할 수 있지만, 로드 밸런서 뒤에서 동일한 인스턴스를 확장하는(상태 비저장 워크로드) 데 최적화되어 있으며, 매주 생성/삭제되는 임시의 사용자 지정 dev/test 머신에는 덜 적합합니다. Reserved Instances는 장기간 실행되는 VM의 비용을 줄이는 것이지 관리 노력을 줄이는 것이 아니며, 수명이 짧고 매주 교체되는 워크로드와는 맞지 않습니다. Microsoft Managed Desktop은 관리형 엔드포인트/데스크톱 서비스로, 빠른 VM 라이프사이클 플랫폼이 아닙니다.
시험 팁:
“developers”, “frequently create and delete”, “customized VMs”, “minimize administrative effort”가 보이면 DevTest Labs를 떠올리세요. “autoscale identical VMs for an app”이면 VM Scale Sets를 떠올리세요. “commitment discount”이면 Reserved Instances를 떠올리세요.
이동 중에도 모든 문제를 풀고 싶으신가요?
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
Cloud Pass를 다운로드하고 모든 Microsoft AZ-900 학습 문제를 무료로 이용하세요.
이동 중에도 모든 문제를 풀고 싶으신가요?
무료 앱 받기
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
2
문제 2
HOTSPOT -
다음 각 진술에 대해, 진술이 참이면 Yes를 선택합니다. 그렇지 않으면 No를 선택합니다.
참고: 각 정답 선택은 1점입니다.
핫 영역:
파트 1:
Azure Advisor는 Azure Backup으로 보호되는 Azure virtual machines 목록을 생성할 수 있습니다.
Azure Advisor는 Azure Backup으로 보호되는 Azure virtual machines의 확정적인 목록을 생성하는 용도로 신뢰할 수 없습니다. Advisor의 목적은 권장 사항을 제공하는 것(예: 백업이 없는 VM을 감지하면 “enable backup for VMs” 권장)이지, 백업으로 보호되는 리소스에 대한 권위 있는 보고용 인벤토리 역할을 하는 것이 아닙니다.
어떤 VM이 보호되는지 목록을 확인하려면 일반적으로 Recovery Services vault/Backup center 보기, Azure Backup reports, 또는 보고 요구 사항에 따라 Azure Resource Graph/Log Analytics를 통한 쿼리를 사용합니다. 이러한 도구는 구독 전반에서 보호 상태, backup items, 및 규정 준수(compliance)를 표시하도록 설계되어 있습니다.
따라서 해당 진술은 거짓입니다. Advisor는 권장 사항으로 누락된 백업을 강조할 수는 있지만, 현재 Azure Backup으로 보호되는 VM의 전체 목록을 생성하는 기본 메커니즘으로 기능하지는 않습니다.
파트 2:
Azure Advisor에서 제공하는 보안 권장 사항을 구현하면 회사의 secure score가 감소합니다.
보안 권장 사항을 구현하면 회사의 Secure Score는 증가하며, 감소하지 않습니다. Secure Score는 구현된 제어 및 해결된 권장 사항을 기반으로 보안 상태를 반영하는 Microsoft Defender for Cloud 메트릭입니다. 권장 사항(예: MFA 활성화, just-in-time VM access 적용, Defender plans 활성화, NSG rules 수정)을 처리할수록 일반적으로 위험을 줄이고 보안 격차를 해소하므로 점수가 올라갑니다.
Azure Advisor는 보안 권장 사항을 표시할 수 있지만, 점수(Scoring) 개념은 Defender for Cloud에 연결되어 있습니다. 시험에서는 이 방향성이 중요합니다. 즉, 개선 조치는 보안 상태를 향상시키고 Secure Score를 올립니다.
따라서 이 문장은 권장 사항을 구현하면 점수가 감소한다고 주장하고 있는데, 이는 Secure Score가 작동하는 방식과 반대이므로 거짓입니다.
파트 3:
Microsoft 지원을 유지하려면 30일 이내에 Azure Advisor에서 제공하는 보안 권장 사항을 구현해야 합니다.
Microsoft 지원을 유지하기 위해 30일 이내에 Azure Advisor 보안 권장 사항을 구현해야 한다는 Microsoft 정책은 없습니다. Azure Advisor 권장 사항은 워크로드를 최적화하고 보안을 강화하는 데 도움이 되도록 제공되는 모범 사례 가이드이며, 선택 사항이고 영향도에 따라 우선순위가 지정됩니다.
Microsoft 지원 자격은 고정된 기한 내에 Advisor 권장 사항을 구현하는지 여부에 달려 있지 않습니다. 지원 요구 사항은 일반적으로 지원되는 제품/버전 사용, 적절한 라이선스 유지, 계약 조건 준수와 관련이 있으며, 특정 기간 내에 권고 가이드를 시정하는 것과는 관련이 없습니다.
규제가 있는 환경에서는 조직이 거버넌스 도구(예: Azure Policy, Defender for Cloud regulatory compliance) 또는 ITSM 프로세스를 사용하여 내부 SLA(예: 높은 심각도의 결과를 30일 이내에 시정)를 설정할 수 있지만, 이는 고객이 정의하는 통제이며 Microsoft 지원 의무 사항이 아닙니다.
따라서 해당 진술은 거짓입니다.
3
문제 3
데이터 센터의 Hyper-V 호스트에서 호스팅되는 1,000개의 virtual machine이 있습니다.
모든 virtual machine을 Azure pay-as-you-go subscription으로 마이그레이션할 계획입니다.
계획된 Azure 솔루션에 사용할 지출 모델을 식별해야 합니다.
어떤 지출 모델을 식별해야 합니까?
Operational expenditure (OpEx)가 정답인 이유는 Azure pay-as-you-go가 consumption-based이며 주기적으로 청구되는 지속적인 운영 비용이기 때문입니다. 1,000개의 VM을 호스팅하기 위해 physical server를 구매하고 소유하는 대신, compute capacity를 임대하고 사용한 만큼 지불합니다. 이는 AZ-900에서 강조하는 전형적인 cloud 재무 전환인 CapEx에서 OpEx로의 이동입니다.
Elastic은 지출 모델이 아니라, 수요에 따라 리소스를 자동으로 또는 빠르게 up/down으로 확장할 수 있는 능력을 설명하는 cloud 특성입니다. Elasticity는 overprovisioning을 피함으로써 운영 비용을 줄이는 데 도움이 될 수 있지만, 지출이 CapEx인지 OpEx인지 정의하지는 않습니다. 따라서 지출 모델을 묻는 문제의 정답이 아닙니다.
Capital expenditure (CapEx)는 데이터 센터를 위한 Hyper-V host, storage array, networking 장비 구매처럼 physical infrastructure 및 장기 자산에 대한 upfront 투자를 의미합니다. 시나리오는 Azure pay-as-you-go subscription을 명시하고 있으며, 이는 upfront 자산 구매가 아니라 지속적인 서비스 소비로 청구되므로 여기서는 CapEx가 올바른 모델이 아닙니다.
Scalable 또한 지출 모델이 아니라, 리소스를 추가하여(Scale out) 또는 용량을 늘려(Scale up) 증가한 부하를 처리할 수 있는 시스템의 능력을 설명합니다. Elasticity와 마찬가지로 scalability는 지출 규모에 영향을 줄 수 있는 cloud 이점이지만, OpEx나 CapEx 같은 회계 분류는 아닙니다.
문제 분석
핵심 개념:
이 문제는 capital expenditure (CapEx)에서 operational expenditure (OpEx)로의 cloud 재무 모델 전환을 평가합니다. Azure에서는 특히 pay-as-you-go subscription을 사용할 때, 하드웨어를 선구매하는 대신 (compute, storage, networking 등) 소비한 만큼을 지속적인 운영 비용으로 지불합니다.
정답이 맞는 이유:
온프레미스 데이터 센터에서 1,000개의 Hyper-V virtual machine을 Azure pay-as-you-go subscription으로 마이그레이션하는 것은 operational expenditure 모델에 부합합니다. 온프레미스는 일반적으로 서버, storage, networking 장비, 데이터 센터 용량을 upfront로 구매해야 하므로 CapEx가 필요합니다. 반면 Azure pay-as-you-go 요금은 metered 방식으로 측정되어 주기적으로(월별) 청구되므로 operating expense가 됩니다. 이는 AZ-900의 기본 개념으로, cloud 서비스는 큰 upfront 투자 비용을 지속적이고 사용량 기반의 비용으로 전환합니다.
주요 기능 / 고려 사항:
Azure에서 OpEx를 사용하면 비용이 사용량에 따라 확장되며, Azure Cost Management + Billing, budgets, tagging, alerts 같은 governance 및 cost management 방식으로 최적화할 수 있습니다. 이 문제는 최적화를 묻지는 않지만, 실제 마이그레이션에서는 Reserved Instances/Savings Plans, Azure Hybrid Benefit(적격 Windows Server license가 있는 경우), rightsizing을 통해 OpEx를 더 줄일 수 있습니다. 이는 할인 조건에 커밋하더라도 시간이 지남에 따라 서비스 소비에 대해 지불하는 형태이므로 여전히 OpEx 지향입니다.
일반적인 오해:
“elastic”와 “scalable”은 cloud 특성(리소스를 up/down으로 확장하는 능력)을 설명하는 용어이지 지출 모델이 아닙니다. 비용 동작에 영향을 줄 수는 있지만 회계 분류는 아닙니다. “capital”은 VM이 많아 큰 프로젝트 투자처럼 보일 수 있어 그럴듯해 보이지만, Azure pay-as-you-go는 인프라 자산을 upfront로 구매하는 방식이 아닙니다.
시험 팁:
AZ-900에서는 subscription/결제 유형을 지출 모델에 매핑하세요:
- Pay-as-you-go cloud services → OpEx.
- 데이터 센터 하드웨어/license를 upfront로 구매 → CapEx.
또한 elasticity/scalability는 cloud 이점이지 재무 모델이 아닙니다. “metered billing”과 “consumption-based pricing”을 OpEx 및 Azure Well-Architected Framework의 Cost Optimization pillar(가시성과 governance를 통해 지속 지출 최적화)와 직접 연결해 기억하세요.
4
문제 4
규칙에 따라 자동으로 이메일 알림을 보내는 온-프레미스 애플리케이션이 있습니다.
애플리케이션을 Azure로 마이그레이션할 계획입니다.
애플리케이션을 위한 serverless computing 솔루션을 권장해야 합니다.
권장 사항에 무엇을 포함해야 합니까?
web app(Azure App Service)은 웹 애플리케이션과 API를 실행하기 위한 PaaS 호스팅 옵션입니다. web app 내부에 이메일 알림을 구현할 수는 있지만, 애플리케이션 코드를 배포하고 관리해야 하며 일반적으로 앱을 지속적으로 사용 가능 상태로 유지해야 합니다. 기본 제공 이메일 커넥터와 실행당 과금 특성을 갖는 serverless, 규칙 기반 워크플로에 가장 적합한 선택은 아닙니다.
Azure Marketplace의 server image는 일반적으로 미리 빌드된 이미지로 virtual machine(IaaS)을 배포하는 것을 의미합니다. 이 경우 VM 크기 조정, 패치, 가용성, 스케일링, 업타임을 관리해야 합니다. 이 접근 방식은 serverless가 아니며, 단순 알림 자동화에는 Logic Apps 같은 관리형 serverless 서비스보다 운영 오버헤드와 비용이 증가합니다.
logic app은 트리거와 액션을 사용해 프로세스를 자동화하는 serverless 워크플로 서비스입니다. 기본 제공 커넥터(Outlook, SMTP, SendGrid), 시각적 설계, 재시도, 모니터링을 인프라 관리 없이 제공하므로 규칙 기반 이메일 알림에 이상적입니다. 자동 알림과 serverless 접근 방식이라는 시나리오 요구 사항에 부합합니다.
API app은(역사적으로 App Service와 연계된) API를 호스팅하기 위한 App Service 기반 접근 방식입니다. 엔드포인트를 노출할 수는 있지만, 워크플로 오케스트레이션, 규칙 평가, 이메일 커넥터를 본질적으로 제공하지는 않습니다. 이메일을 보내려면 여전히 로직을 구축하고 추가 서비스를 통합해야 하므로, 이 serverless 자동화 시나리오에서는 Logic Apps보다 덜 적합합니다.
문제 분석
핵심 개념:
이 문제는 워크플로 기반 자동화를 위한 Azure serverless 옵션을 식별하는지를 평가합니다. Azure Fundamentals에서 “serverless”는 일반적으로 Azure Functions(코드 중심)와 Azure Logic Apps(워크플로/로우코드)에 해당합니다. 시나리오는 규칙에 따라 자동으로 이메일 알림을 보내는 것으로, 전형적인 이벤트 기반 워크플로입니다.
정답이 맞는 이유:
Azure Logic Apps는 트리거(예: “레코드가 생성될 때”, “일정에 따라”, “HTTP 요청을 수신할 때”)와 액션(예: “이메일 보내기”, “Teams에 게시”, “티켓 생성”)을 사용해 워크플로를 오케스트레이션하도록 설계되었습니다. 이는 serverless로, 서버를 관리하지 않으며 스케일링은 플랫폼이 처리하고, 일반적으로 플랜에 따라 실행/Consumption 기준으로 과금됩니다. 규칙에 따라 이메일 알림을 보내는 애플리케이션의 경우, Logic Apps는 기본 제공 커넥터(Office 365 Outlook, SMTP, SendGrid 등)를 사용해 최소한의 사용자 지정 코드로 규칙 평가와 이메일 전송을 구현할 수 있습니다.
주요 기능 / 모범 사례:
Logic Apps는 수백 개의 커넥터, 기본 제공 재시도 정책, 오류 처리, 그리고 Azure Monitor 및 run history를 통한 모니터링을 제공합니다. 이는 Azure Well-Architected Framework 원칙(운영 우수성: 시각적 워크플로, run history / 신뢰성: 재시도, 복원력 있는 커넥터 / 비용 최적화: Consumption에서 pay-per-use)과 부합합니다. 이메일 알림의 경우, 관리형 커넥터를 사용하면 유지 관리가 줄고, 지원되는 경우 managed identities 및 Azure AD를 통해 보안이 향상됩니다.
흔한 오해:
web app(App Service)도 이메일을 보낼 수 있지만, 시험에서 말하는 의미의 serverless는 아니며 일반적으로 애플리케이션을 지속적으로 호스팅해야 합니다. Azure Marketplace의 server image는 IaaS(VM 기반)로 serverless의 반대입니다. API app은 API를 호스팅하기 위한 App Service 기능으로, 규칙 기반 워크플로 자동화를 직접 제공하지 않으며 “규칙에 따라 이메일 전송”에 가장 적합한 선택이 아닙니다(추가 구성 요소 없이).
시험 팁:
“규칙에 따라 자동으로”, “워크플로”, “커넥터”, “노/로우 코드”, “이메일 전송”이 보이면 Logic Apps를 떠올리세요. “필요할 때 코드 실행” 또는 “이벤트 기반 코드”가 보이면 Azure Functions를 떠올리세요. AZ-900에서는 알림 시나리오에 가장 직접적인 serverless 워크플로 서비스가 Logic Apps입니다.
5
문제 5
(2개 선택)
지원 엔지니어가 Azure CLI를 사용하여 여러 Azure 관리 작업을 수행할 계획입니다.
컴퓨터에 CLI를 설치합니다.
지원 엔지니어에게 CLI를 실행하는 데 사용할 도구를 알려야 합니다.
지원 엔지니어에게 어떤 두 가지 도구를 사용하라고 안내해야 합니까? 각 정답은 완전한 솔루션을 제시합니다.
참고: 각 정답 선택은 1점입니다.
Command Prompt는 PATH에 있는 실행 파일(예: Azure CLI의 `az`)을 실행할 수 있는 Windows 명령줄 셸입니다. 설치 후 cmd.exe를 열고 `az login`, `az account show` 같은 명령을 실행할 수 있습니다. Windows에서 Azure CLI 명령을 실행하기 위한 유효하고 일반적인 환경입니다.
Azure Resource Explorer는 Azure portal의 웹 기반 도구로, Azure Resource Manager(ARM) 리소스 정의와 속성을 보고 상호작용하는 데 사용됩니다. 리소스 JSON을 검사하고 문제를 해결하는 데 도움이 되지만, 명령줄 셸이 아니며 Azure CLI(`az`) 명령을 실행하지 않습니다.
Windows PowerShell은 Windows의 스크립팅 및 자동화 셸로, Azure CLI 같은 명령줄 도구를 실행할 수 있습니다. CLI 설치 후 PowerShell에서 `az` 명령을 직접 실행하고 스크립트로 작업을 자동화할 수 있습니다. PowerShell은 관리자가 흔히 사용하며 자동화 및 운영 우수성 관행과 잘 맞습니다.
Windows Defender Firewall은 Windows 컴퓨터에서 인바운드 및 아웃바운드 네트워크 트래픽을 제어하는 호스트 방화벽입니다. 터미널이나 스크립팅 환경이 아니므로 Azure CLI 명령을 실행하는 데 사용할 수 없습니다. 방화벽 규칙이 Azure 엔드포인트에 대한 연결에 영향을 줄 수는 있지만, CLI를 실행하는 도구는 아닙니다.
Network and Sharing Center는 네트워크 연결 및 공유 설정을 확인하고 구성하기 위한 Windows 제어판 인터페이스입니다. Azure 관리 도구와는 관련이 없으며 Azure CLI를 실행할 수 있는 명령줄 인터페이스를 제공하지 않습니다.
문제 분석
핵심 개념:
이 문제는 Azure CLI를 설치한 후 Azure CLI 명령을 어떻게 실행하는지 테스트합니다. Azure CLI는 Azure 리소스를 관리(생성, 구성, 쿼리, 삭제)하는 데 사용되는 크로스 플랫폼 명령줄 도구(실행 파일은 일반적으로 `az`)이며, Azure portal, Azure PowerShell, ARM/Bicep, REST APIs와 함께 Azure의 관리 도구에 포함됩니다.
정답이 맞는 이유:
Windows에서 Azure CLI가 설치되면 지원되는 어떤 명령 셸에서든 `az` 명령을 실행할 수 있습니다. 일반적이며 완전히 지원되는 두 가지 셸은 Command Prompt(cmd.exe)와 Windows PowerShell입니다. 둘 다 `az` 실행 파일을 호출하고(예: `az login`), 인증한 뒤, 관리 작업(예: `az group create`, `az vm list`)을 수행할 수 있는 대화형 터미널을 제공합니다. 따라서 엔지니어에게 Command Prompt와 Windows PowerShell을 사용하라고 안내하는 것은 완전한 솔루션입니다.
주요 기능 및 모범 사례:
Azure CLI는 스크립팅과 자동화를 지원하며, 이는 Azure Well-Architected Framework의 운영 우수성(반복 가능한 배포, 수동 오류 감소, 일관된 구성)과 부합합니다. 실제로 엔지니어는 Windows에서 더 풍부한 스크립팅을 위해 PowerShell을 자주 사용하고, Command Prompt는 간단하고 어디서나 사용할 수 있는 셸입니다. Azure CLI는 Azure Cloud Shell에서도 사용할 수 있지만, 이 옵션은 여기에는 나열되어 있지 않습니다.
일반적인 오해:
일부는 “Azure 관리 도구”를 “Azure CLI를 실행하는 도구”와 혼동할 수 있습니다. Azure Resource Explorer는 ARM 리소스를 보고 문제를 해결하기 위한 portal 기반 리소스 검사 도구이며, Azure CLI 명령을 실행하지 않습니다. Windows Defender Firewall과 Network and Sharing Center는 네트워킹/보안 구성 도구로, 명령줄 관리 명령 실행과는 관련이 없습니다.
시험 팁:
AZ-900에서는 다음을 기억하세요: Azure CLI는 터미널/셸(PowerShell, Command Prompt, Bash, Cloud Shell)에서 실행합니다. 옵션이 셸/터미널이라면 정답일 가능성이 큽니다. portal 기능이나 Windows 제어판 애플릿이라면 CLI 실행 환경이 아닙니다.
6
문제 6
HOTSPOT -
10개의 웹 앱을 포함하는 Azure 환경이 있습니다. 모든 Azure 리소스를 관리하려면 어떤 URL에 연결해야 합니까? 답하려면, 답안 영역에서 적절한 옵션을 선택하십시오.
참고: 각 정답 선택은 1점입니다.
핫 영역:
파트 1:
프로토콜
정답은 B (portal.)입니다. Azure portal은 https://portal.azure.com 에서 접속하며, 구독, 리소스 그룹, 서비스 전반(10개의 web app 모두 포함)에 걸친 모든 Azure 리소스를 관리하기 위한 표준 웹 인터페이스입니다. portal은 Azure management plane의 일부이며 RBAC, policy, resource locks, cost management와 같은 governance 기능을 통합합니다.
A (admin.)은 Azure의 글로벌 management portal에 대한 표준 서브도메인이 아닙니다. 일부 서비스는 다른 Microsoft 제품에서 admin 관련 endpoint를 가질 수 있지만, Azure 리소스 관리는 admin.azure.com URL을 통해 수행되지 않습니다.
C (www.)는 일반적인 공개 웹사이트 접두사이지만 Azure portal에는 사용되지 않습니다. www.azure.com을 사용하면 리소스를 관리하는 데 필요한 인증된 management 경험이 아니라 marketing/documentation 페이지로 이동합니다.
파트 2:
도메인
정답은 A(azure.)입니다. 전체 포털 URL은 portal.azure.com이기 때문입니다. azure.com 도메인은 Azure의 주요 웹 프레즌스에 사용되며 인증된 포털 엔드포인트를 포함합니다.
B(azurewebsites.)는 Azure App Service 기본 애플리케이션 호스트네임(예: <appname>.azurewebsites.net)과 연관됩니다. 해당 도메인은 배포된 웹 애플리케이션에 접근하기 위한 것(data plane / app endpoint)이지, 모든 Azure 리소스를 관리하기 위한 것이 아닙니다. 특정 web app을 탐색하는 데는 사용할 수 있지만, subscription, resource group, networking, identity 등은 관리할 수 없습니다.
C(microsoft.)는 Azure portal에 사용되는 도메인이 아닙니다. Microsoft가 Azure를 소유하고 있기는 하지만, 이 문맥에서 Azure 리소스 관리를 위한 포털은 portal.microsoft.com에 호스팅되지 않습니다.
7
문제 7
Azure에서 Infrastructure as a Service (IaaS) 리소스를 프로비저닝할 계획입니다.
다음 중 IaaS의 예에 해당하는 리소스는 무엇입니까?
Azure web app(Azure App Service)은 IaaS가 아니라 PaaS입니다. application code를 배포하고 설정(runtime, scaling rules, custom domains)을 구성하지만, Microsoft가 기본 servers, OS patching, platform maintenance를 관리합니다. plans/tiers를 선택하기 때문에 “infrastructure”처럼 보일 수 있으나, IaaS의 핵심 지표인 VM OS layer를 관리하지 않습니다.
Azure virtual machine은 IaaS입니다. compute resources를 프로비저닝하고 OS image와 VM size를 선택한 다음, guest OS, patches, 설치된 software, application stack을 관리합니다. Microsoft는 물리적 hardware, datacenter, hypervisor를 관리합니다. 이러한 명확한 책임 분리는 IaaS의 특징이며, IaaS 예시로서 가장 적절한 정답입니다.
Azure Logic App은 PaaS(serverless integration/workflow)입니다. connectors와 triggers를 사용해 workflows를 설계하면 Azure가 실행 환경을 대신 실행하고 확장합니다. 사용자가 관리할 VM이나 OS가 없습니다. 여러 시스템과 통합되고 infrastructure automation의 일부가 될 수 있어 IaaS로 혼동될 수 있지만, 이는 관리형 platform 서비스입니다.
Azure SQL Database는 PaaS(managed database)입니다. Microsoft가 OS 관리, SQL engine patching, backups(보존 기간 구성 가능), 그리고 tier에 따른 high availability 옵션을 처리합니다. 사용자는 database schema, queries, security configuration(예: firewall rules, authentication), data를 관리합니다. 기본 server/OS를 관리하지 않으므로 IaaS가 아닙니다.
문제 분석
핵심 개념:
이 문제는 클라우드 서비스 모델인 Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS)를 평가합니다. AZ-900에서는 무엇을 누가 관리하는지(고객 vs. Microsoft)에 따라 각 모델에 매핑되는 Azure 오퍼링을 구분할 수 있어야 합니다.
정답이 맞는 이유:
Azure virtual machine (VM)은 전형적인 IaaS 리소스입니다. IaaS에서는 Microsoft가 기본 물리적 datacenter, networking, storage infrastructure, 그리고 virtualization layer를 제공하고 관리합니다. 고객(사용자)은 guest operating system 구성 및 관리, 해당 OS의 patches 및 updates, 설치된 software/runtime, application configuration, 그리고 VM 내부의 보안 제어(예: host firewall rules, endpoint protection)를 담당하는 경우가 많습니다. 이는 compute infrastructure를 임대하면서 상당한 제어 권한을 유지한다는 IaaS 정의와 정확히 일치합니다.
주요 기능 및 모범 사례:
Azure VMs를 사용하면 OS images, VM sizes, disks (managed disks), networking (VNets, NICs, NSGs)를 선택할 수 있습니다. 복원력(Azure Well-Architected Framework: Reliability)을 위해 일반적으로 Availability Sets 또는 Availability Zones를 사용하고, 가능하면 scale-out을 고려해 설계합니다. 보안(Security pillar)을 위해 least privilege를 적용하고, NSGs를 사용하며, Azure Backup을 활성화하고, patching을 위해 Azure Update Manager/automation을 고려합니다. 비용 최적화를 위해 VM SKUs를 적정 규모로 조정하고, Reserved Instances/Savings Plans를 사용하며, 필요하지 않을 때 dev/test VMs를 종료합니다.
흔한 오해:
많은 Azure 서비스는 Azure에 배포하기 때문에 “infrastructure”처럼 느껴질 수 있지만, PaaS 서비스는 OS 관리를 추상화합니다. Web Apps, Logic Apps, Azure SQL Database는 PaaS로, Microsoft가 OS와 platform 구성 요소를 관리하고 사용자는 code, workflows 또는 data에 집중합니다.
시험 팁:
OS(patching, configuration, installed software)를 관리한다면 거의 항상 IaaS(VMs)입니다. servers/OS를 관리하지 않고 code를 배포한다면 PaaS(App Service, Logic Apps, Azure SQL Database)입니다. shared responsibility model을 기억하세요. 일반적으로 고객 책임이 더 많을수록 IaaS일 가능성이 큽니다.
8
문제 8
참고: 이 질문은 동일한 시나리오를 제시하는 일련의 질문 중 일부입니다. 시리즈의 각 질문에는 명시된 목표를 충족할 수 있는 고유한 솔루션이 포함되어 있습니다. 일부 질문 세트에는 정답이 둘 이상 있을 수 있으며, 다른 세트에는 정답이 없을 수도 있습니다.
이 섹션에서 질문에 답한 후에는 해당 질문으로 돌아갈 수 없습니다. 따라서 이러한 질문은 검토 화면에 표시되지 않습니다.
회사에는 다음과 같은 미사용 리소스가 포함된 Azure 구독이 있습니다.
✑ Azure Active Directory (Azure AD)의 사용자 계정 20개
✑ Azure AD의 그룹 5개
✑ 공용 IP 주소 10개
✑ 네트워크 인터페이스 10개
회사에 대한 Azure 비용을 줄여야 합니다.
솔루션: 미사용 그룹을 제거합니다.
이것이 목표를 충족합니까?
예는 Azure AD 그룹이 삭제로 줄일 수 있는 지속적인 Azure 요금을 발생시킨다고 가정하기 때문에 오답입니다. 실제로 Azure AD 그룹은 객체당 직접 비용이 발생하지 않으며, 요금은 일반적으로 라이선스 등급과 프리미엄 기능에 연관되고 그룹 수와는 관련이 없습니다. 그룹을 제거하면 관리가 단순해질 수는 있지만 Azure 리소스 사용량 청구를 낮추지는 않습니다. 비용을 줄이려면 할당된 공용 IP 주소 또는 기타 계량형 서비스와 같은 과금 대상 리소스를 대상으로 해야 합니다.
아니요가 정답인 이유는 미사용 Azure AD 그룹을 삭제해도 Azure 사용량 요금이 줄어들지 않기 때문입니다. Azure AD 그룹은 디렉터리 객체이며 표준 Azure 청구에서 그룹당 과금되지 않습니다. 비용 절감은 공용 IP 주소(특히 할당된 경우) 또는 기타 계량형 서비스와 같은 과금 대상 리소스를 제거하거나 할당 해제함으로써 이루어집니다. 따라서 그룹을 제거하는 것은 Azure 비용을 줄인다는 목표를 충족하지 않습니다.
문제 분석
핵심 개념:
이 질문은 어떤 Azure 리소스가 지속적인 요금을 발생시키는지, 그리고 어떤 리소스가 무료인지 테스트하여 Azure 비용을 실제로 줄이는 조치를 식별할 수 있는지 확인합니다.
정답이 맞는 이유:
미사용 Azure AD 그룹을 제거해도 Azure 비용은 줄어들지 않습니다. 일반적인 Azure 구독 청구 모델에서 Azure AD 그룹 자체는 그룹당 요금이 부과되지 않기 때문입니다. Azure AD의 비용은 일반적으로 그룹의 존재 여부가 아니라 사용자에 대한 라이선스(예: Microsoft Entra ID Free/P1/P2) 및 사용 중인 프리미엄 기능에 의해 결정됩니다. 따라서 그룹을 삭제해도 청구 금액이 의미 있게 변하지 않으며, 반면 다른 나열된 리소스(특히 공용 IP 주소)는 할당되어 있으면 요금이 발생할 수 있습니다.
주요 기능/구성:
- Microsoft Entra ID (Azure AD) 객체(사용자, 그룹)는 디렉터리 객체이며 객체당 과금되지 않습니다.
- Azure 비용은 일반적으로 컴퓨팅, 스토리지, 대역폭, 그리고 특정 네트워킹 할당과 같은 계량형(metered) 리소스에 의해 발생합니다.
- 공용 IP 주소는 예약/할당된 경우(특히 Standard SKU) 연결/사용되지 않더라도 과금될 수 있습니다.
흔한 오해:
- “미사용” 디렉터리 객체(사용자/그룹)가 컴퓨팅/네트워크 리소스처럼 Azure 사용량 요금을 발생시킨다고 가정하는 것.
- Microsoft 365/Entra 라이선스 비용(사용자/기능당)과 Azure 리소스 사용량 비용(계량형 사용량)을 혼동하는 것.
- 할당된 네트워킹 리소스(예: 공용 IP)가 유휴 상태에서도 비용이 발생할 수 있다는 점을 간과하는 것.
시험 팁:
- 비용 최적화는 디렉터리 객체가 아니라 계량형 Azure 리소스(컴퓨팅, 디스크, 공용 IP, 게이트웨이)에 집중하세요.
- 기억하세요: Entra ID 그룹은 Azure 사용량 비용 항목이 직접적으로 발생하지 않으며, 라이선스는 일반적으로 사용자/기능 기준입니다.
- 네트워킹의 경우 리소스가 단순히 객체로 정의된 것인지, 아니면 “할당/예약”(종종 과금됨) 상태인지 확인하세요.
9
문제 9
HOTSPOT -
다음 각 진술에 대해, 진술이 참이면 Yes를 선택합니다. 그렇지 않으면 No를 선택합니다.
참고: 각 정답 선택은 1점입니다.
핫 영역:
파트 1:
private preview 상태의 Azure 서비스는 모든 Azure 고객에게 릴리스됩니다.
아니요. private preview 상태의 서비스는 모든 Azure 고객에게 릴리스되지 않습니다. private preview는 의도적으로 소수의 선정된 그룹으로 제한되며(대개 초대, 신청, 또는 추천을 통해), Microsoft가 통제된 피드백을 바탕으로 기능, 성능, 보안, 사용성을 검증할 수 있도록 합니다.
private preview에서는 기능이 미완성일 수 있고, 문서가 제한적일 수 있으며, 호환성을 깨는 변경(breaking changes)이 발생할 가능성이 더 큽니다. 일반적으로 SLA가 포함되지 않으며, 광범위한 프로덕션 사용을 목적으로 하지 않습니다. 접근이 제한되어 있으므로 “모든 Azure 고객에게 릴리스됨”으로 볼 수 없습니다.
“예”가 틀린 이유: “모든 고객에게 릴리스됨”은 public preview(옵트인) 또는 general availability(완전 릴리스)에 더 가깝고, private preview가 아닙니다. private preview는 릴리스 라이프사이클에서 가장 제한적인 단계입니다.
파트 2:
공개 미리 보기(public preview) 상태의 Azure 서비스는 모든 Azure 고객에게 릴리스됩니다.
예. 공개 미리 보기(public preview) 상태의 서비스는 일반적으로 Azure 고객이 사용해 볼 수 있도록 제공되며, 즉 특정 소수에게만 제공되는 것이 아니라 광범위하게 릴리스됩니다. 공개 미리 보기에서는 고객이 보통 직접(옵트인) 서비스를 활성화하거나 배포할 수 있지만, 지원되는 지역, 특정 구독 유형, 할당량, 기능 공백과 같은 제한이 있을 수 있습니다.
공개 미리 보기(public preview)는 프로덕션 관점에서는 여전히 정식 릴리스 이전 단계입니다. Microsoft는 종종 SLA 없이 제공하며, 미션 크리티컬한 프로덕션 워크로드에는 권장하지 않을 수 있습니다. 하지만 시험의 핵심 개념은 공개 미리 보기(public preview)가 초대 전용이 아니라 일반 대중(Azure 고객)에게 공개된다는 점입니다.
“아니요”가 틀린 이유: “아니요”는 비공개 미리 보기(private preview)(제한된 액세스)를 설명하는 경우에 해당합니다. 공개 미리 보기(public preview)는 아직 모든 지역이나 모든 시나리오에서 제공되지 않더라도, 제한된 파일럿 그룹을 넘어 액세스를 확대합니다.
파트 3:
일반적으로 General Availability 상태인 Azure 서비스는 일부 Azure 고객에게만 릴리스됩니다.
아니요. General Availability(GA)는 해당 서비스가 프로덕션 사용을 위해 완전히 릴리스되었으며 Azure 고객에게 광범위하게 제공됨을 의미합니다. GA에는 일반적으로 완전한 지원 가능성(supportability)과, 해당되는 경우 공개된 SLA가 포함됩니다. 핵심 특징은 더 이상 preview가 아니며 주류 도입을 위한 준비가 되었다고 간주된다는 점입니다.
Microsoft가 때때로 GA 기능을 지역 또는 클라우드(공용 vs sovereign)별로 점진적으로 출시할 수는 있지만, GA를 고객의 일부에게만 릴리스되는 것으로 설명하지는 않습니다. “일부 고객”이라는 표현은 private preview(초대 전용) 또는 limited preview 프로그램에 더 부합합니다.
“예”가 틀린 이유: 서비스가 일부 고객에게만 제공된다면 진정한 GA가 아니며, General Availability라기보다는 private preview 또는 제한적/통제된 릴리스로 분류하는 것이 더 정확합니다.
10
문제 10
(2개 선택)
귀사는 Azure로 마이그레이션할 계획입니다.
회사에는 여러 부서가 있습니다. 각 부서에서 사용하는 모든 Azure 리소스는 부서 관리자가 관리합니다.
부서별로 Azure를 분할하는 두 가지 가능한 기법은 무엇입니까? 각 정답은 완전한 솔루션을 제시합니다.
참고: 각 정답 선택은 1점입니다.
여러 구독은 부서에 대해 강력한 경계를 제공합니다. 즉, 별도의 청구/차지백, 독립적인 서비스 할당량/제한, 명확한 관리 분리가 가능합니다. 부서 관리자가 부서의 모든 리소스를 관리할 수 있도록 구독 범위에서 RBAC 역할을 할당할 수 있습니다. 이는 특히 부서에 독립적인 예산과 보고가 필요할 때 거버넌스 및 비용 관리를 위한 일반적인 엔터프라이즈 패턴입니다.
여러 Azure AD 디렉터리(테넌트)는 주로 ID를 분할하며, 동일 회사 내 부서의 일상적인 리소스 구성을 위한 것이 아닙니다. 별도의 디렉터리를 사용하면 복잡성(사용자 수명 주기, 테넌트 간 협업, 라이선싱, 관리)이 증가합니다. 가능하긴 하지만, Azure 거버넌스에서 부서 분할을 위해 구독/리소스 그룹과 비교했을 때 일반적인 기법은 아닙니다.
여러 지역은 지연 시간, 규정 준수/데이터 상주, 복원력/DR을 위해 워크로드를 지리적으로 배치하는 데 사용됩니다. 지역은 부서에 대한 관리 또는 거버넌스 경계를 제공하지 않습니다. 부서 관리자는 동일한 구독/리소스 그룹 내에서 여러 지역에 걸친 리소스를 여전히 관리할 수 있으므로, 지역은 부서 관리를 위한 분할 기법이 아닙니다.
여러 리소스 그룹은 구독 내에서 리소스를 논리적으로 분할합니다. 리소스 그룹 범위에서 RBAC 역할을 할당할 수 있으므로 부서 관리자가 해당 그룹의 리소스만 관리하도록 위임하는 데 이상적입니다. 또한 리소스 그룹은 수명 주기 관리(단위로 배포/업데이트/삭제)와 Azure Policy 및 태그 지정을 통한 거버넌스를 지원합니다.
문제 분석
핵심 개념:
이 문제는 Azure 관리 및 거버넌스 분할을 평가합니다. Azure에서는 위임된 관리, 액세스 제어(RBAC), 정책 적용, 비용 추적을 지원하는 관리 경계를 사용하여 서로 다른 팀/부서의 리소스를 분할하는 것이 일반적입니다. 이를 위한 주요 구성 요소는 구독과 리소스 그룹입니다(목록에는 없지만 management group도 종종 보완적으로 사용됨).
정답이 맞는 이유:
A. 여러 구독은 구독이 강력한 격리 및 청구 경계이므로 정답입니다. 각 부서가 자체 구독을 가질 수 있어 별도의 비용 관리/차지백, 독립적인 할당량 제한, 더 명확한 관리 분리가 가능합니다. 부서 관리자에게 구독 범위에서 역할(예: Owner/Contributor)을 할당하여 다른 부서에 영향을 주지 않고 해당 부서의 리소스에 대한 광범위한 제어 권한을 부여할 수 있습니다.
D. 여러 리소스 그룹도 리소스 그룹이 동일한 수명 주기, 권한, 거버넌스 제어를 공유하는 리소스의 논리적 컨테이너이므로 정답입니다. 리소스 그룹 범위에서 부서 관리자에게 RBAC 역할을 할당하여 관리를 위임할 수 있습니다. 또한 리소스 그룹은 Azure Policy 및 태그를 일관되게 적용하는 것을 지원하며, 관련 리소스를 배포, 업데이트, 삭제하는 등의 작업을 단순화합니다.
주요 기능 및 모범 사례:
구독: 청구 분리, 할당량 경계, 강력한 관리 범위. 부서에 독립적인 예산과 제한이 필요할 때 부서 분리에 자주 사용됩니다.
리소스 그룹: 수명 주기 관리, RBAC 범위 지정, 정책 적용, 애플리케이션/환경/부서별 리소스 구성.
Azure Well-Architected Framework의 거버넌스 관점에서 두 접근 방식 모두 비용 관리(Cost Optimization), 운영 관리(Operational Excellence), 최소 권한(Security)을 통한 보안을 지원합니다.
일반적인 오해:
여러 Azure AD 디렉터리(테넌트)는 ID 환경을 분리할 수 있지만, 한 회사 내에서 부서를 분할하는 일반적이거나 권장되는 방식은 아닙니다. 복잡성(테넌트 간 액세스, 중복된 ID)을 증가시키며 부서에 대한 최적의 리소스 거버넌스 모델을 본질적으로 제공하지 않습니다.
여러 지역은 지연 시간, 복원력, 데이터 상주 요구 사항을 위한 지리적 배치와 관련이 있으며 관리 분할과는 관련이 없습니다.
시험 팁:
AZ-900에서는 다음을 기억하세요: 구독은 청구 및 할당량의 기본 경계이고, 리소스 그룹은 구독 내에서 리소스를 구성하고 액세스를 위임하기 위한 기본 경계입니다. 문제가 부서별 관리 및 분할을 강조한다면 구독 및/또는 리소스 그룹이 정답으로 가장 적합합니다.
