모든 답안은 3개의 최고 AI 모델로 교차 검증하여 최고의 정확도를 보장합니다. 선택지별 상세 해설과 심층 문제 분석을 제공합니다.
GPT Pro
Claude Opus
Gemini Pro
선택지별 상세 해설
심층 문제 분석
3개 모델 합의 정확도
연습 문제
1
문제 1
HOTSPOT -
다음 각 문장에 대해 문장이 참이면 Yes를 선택합니다. 그렇지 않으면 No를 선택합니다.
참고: 각 정답 선택은 1점입니다.
핫 영역:
파트 1:
Azure에서 web apps를 호스팅하는 platform as a service (PaaS) 솔루션은 애플리케이션을 호스팅하는 operating systems에 대한 완전한 제어를 제공합니다.
아니요. Azure App Service와 같은 PaaS web hosting 솔루션에서는 애플리케이션을 호스팅하는 operating systems에 대한 완전한 제어를 할 수 없습니다. Microsoft가 patching, updates 및 host configuration의 상당 부분을 포함하여 기본 OS를 관리합니다. 사용자가 제어하는 범위는 application layer에 집중되며, code 배포, app settings 구성, connection strings, certificates(플랫폼 제약 내), 그리고 지원되는 runtimes/stacks 선택 등이 해당됩니다.
“OS에 대한 완전한 제어”는 Infrastructure as a Service (IaaS)의 특징으로, Azure Virtual Machines를 실행하여 OS를 구성하고, agents를 설치하고, system settings를 변경하며, patching을 관리할 수 있습니다(추가 managed services를 사용하지 않는 경우). PaaS는 운영 오버헤드를 줄이고, 표준화된 provider-managed hosting을 통해 보안과 신뢰성을 향상시키기 위해 의도적으로 OS 수준 접근을 제한합니다.
파트 2:
Azure에서 web app을 호스팅하는 platform as a service (PaaS) 솔루션은 플랫폼을 자동으로 확장할 수 있는 기능을 제공합니다.
예. Azure에서 web app을 호스팅하는 PaaS 솔루션은 일반적으로 자동으로 확장할 수 있는 기능을 제공합니다. Azure App Service에서는 scale out(인스턴스 수 증가)할 수 있으며, 플랜에 따라 scale up(더 많은 CPU/RAM/기능을 제공하는 상위 tier로 이동)도 가능합니다. Autoscale 규칙은 CPU 비율, memory, HTTP queue length 또는 일정(schedules)과 같은 메트릭에 반응하도록 구성할 수 있습니다.
이는 PaaS의 핵심 이점입니다. 즉, VM scale sets, load balancers 또는 OS images를 직접 설계하고 관리하지 않아도 플랫폼이 기본 제공되는 elasticity를 제공합니다. 시험 관점에서 “automatic scaling”은 PaaS 특성과 매우 강하게 부합하며, 반응형 용량 관리를 가능하게 함으로써 Azure Well-Architected Framework의 Performance Efficiency 및 Reliability pillar를 지원합니다.
파트 3:
Azure에서 web apps를 호스팅하는 platform as a service (PaaS) 솔루션은 사용자 지정 애플리케이션에 기능을 지속적으로 추가하기 위한 전문 개발 서비스를 제공합니다.
아니요. PaaS web hosting platform은 “사용자 지정 애플리케이션에 기능을 지속적으로 추가하기 위한 전문 개발 서비스”를 제공하지 않습니다. PaaS는 호스팅 환경과 플랫폼 기능(런타임, scaling, 배포 기능, 모니터링 hooks)을 제공하지만, 사람이 주도하는 개발 서비스를 제공하지는 않습니다.
지속적인 기능 제공은 일반적으로 Azure DevOps 또는 GitHub(리포지토리, pipelines, CI/CD)와 같은 DevOps 관행 및 도구와 애플리케이션 수명 주기 관리 프로세스, 그리고 개발 팀을 통해 달성됩니다. Azure는 개발을 지원하는 서비스(예: Azure DevOps, GitHub Actions, Application Insights)를 제공하지만, 이는 도구와 플랫폼일 뿐 사용자 지정 앱에 자동으로 기능을 추가해 주는 전문 서비스는 아닙니다. 따라서 해당 진술은 PaaS 호스팅의 특성이 아닙니다.
이동 중에도 모든 문제를 풀고 싶으신가요?
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
Cloud Pass를 다운로드하고 모든 Microsoft AZ-900 학습 문제를 무료로 이용하세요.
이동 중에도 모든 문제를 풀고 싶으신가요?
무료 앱 받기
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
2
문제 2
HOTSPOT -
여러 지원 엔지니어가 다음 표에 표시된 컴퓨터를 사용하여 Azure를 관리할 계획입니다:
이름 운영 체제
Computer1 Windows 10
Computer2 Ubuntu
Computer3 MacOS Mojave
각 컴퓨터에서 사용할 수 있는 Azure 관리 도구를 식별해야 합니다.
각 컴퓨터에 대해 무엇을 식별해야 합니까? 답하려면 답안 영역에서 적절한 옵션을 선택하십시오.
참고: 각 정답 선택은 1점입니다.
핫 영역:
파트 1:
Computer1:
Computer1은 Windows 10을 실행합니다. Azure portal은 Windows의 모든 최신 웹 브라우저에서 액세스할 수 있으므로 지원됩니다. Azure CLI는 Windows에서 지원되며(MSI, winget 또는 기타 패키지 방법을 통해 설치) Azure Cloud Shell을 통해서도 사용할 수 있습니다. Azure PowerShell은 Windows에서 지원되며(Windows PowerShell 5.1 및 PowerShell 7+), Az PowerShell module은 Azure 리소스를 관리하기 위한 표준입니다.
다른 선택지가 틀린 이유: A, B, C는 각각 Windows에서 사용할 수 있는 도구 중 최소 하나를 누락합니다. Windows는 portal, CLI 및 PowerShell을 모두 지원하므로, 가장 완전하고 올바른 선택지는 D입니다.
파트 2:
Computer2:
Computer2는 Ubuntu (Linux)를 실행합니다. Azure portal은 Ubuntu에서 브라우저로 동작하므로 지원됩니다. Azure CLI는 기본적으로 크로스 플랫폼이며 Microsoft의 apt repository를 통해 Ubuntu에 일반적으로 설치되며, Cloud Shell에서도 사용할 수 있습니다. Azure PowerShell도 PowerShell 7+를 설치한 다음 Az module(Install-Module Az)을 설치하면 Linux에서 지원됩니다. 이는 중요한 AZ-900 포인트입니다. Azure PowerShell은 더 이상 Windows로 제한되지 않습니다.
다른 선택지가 틀린 이유: A는 Ubuntu에서 지원됨에도 Azure PowerShell을 제외합니다. B는 Azure CLI를 제외합니다. C는 portal을 제외합니다. 따라서 D가 정답입니다.
파트 3:
Computer3:
Computer3는 macOS Mojave를 실행합니다. Azure portal은 브라우저 기반이며 macOS에서 작동합니다. Azure CLI는 macOS를 지원하며 Homebrew(일반적인 방식) 또는 기타 설치 프로그램을 통해 설치할 수 있고, Cloud Shell도 선택지입니다. Azure PowerShell은 PowerShell 7+(pwsh)를 설치한 다음 Az module을 설치하면 macOS에서 지원됩니다. 시험 관점에서 Microsoft는 일관된 관리 및 자동화를 가능하게 하기 위해 세 가지 도구 모두를 Windows, Linux 및 macOS 전반에서 사용할 수 있는 것으로 제시합니다.
다른 선택지가 틀린 이유: A와 B는 각각 지원되는 도구 중 하나를 제외하고, C는 portal을 제외합니다. macOS는 portal, CLI 및 PowerShell을 모두 사용할 수 있으므로 D만이 완전히 올바른 선택입니다.
3
문제 3
귀사는 여러 비즈니스 유닛을 보유하고 있습니다.
각 비즈니스 유닛은 일상 운영을 위해 20개의 서로 다른 Azure 리소스가 필요합니다. 모든 비즈니스 유닛은 동일한 유형의 Azure 리소스를 필요로 합니다.
Azure 리소스 생성을 자동화하는 솔루션을 권장해야 합니다.
권장 사항에 무엇을 포함해야 합니까?
Azure Resource Manager (ARM) templates가 정답인 이유는 여러 Azure 리소스의 배포를 코드로 자동화하고 표준화하기 때문입니다. 필요한 20개 리소스를 한 번 정의한 뒤 parameters(이름, regions, SKUs, tags)를 사용해 각 비즈니스 유닛에 대해 재배포할 수 있습니다. ARM templates는 반복 가능하고 멱등적인 배포를 제공하며 CI/CD와 통합되어 일관된 환경과 운영 우수성을 지원합니다.
Virtual machine scale sets는 고가용성과 탄력성을 위해 동일한 VMs 집합을 배포하고 자동으로 확장하도록 설계되었습니다. 단일 표준화된 환경으로서 다양한 Azure 리소스(예: VNets, storage accounts, Key Vault, databases)를 더 폭넓게 프로비저닝하는 것을 자동화하지는 않습니다. Scale sets는 compute 확장에 초점이 있으며, 여러 비즈니스 유닛을 위한 전체 환경 생성이 목적이 아닙니다.
Azure API Management는 APIs를 게시, 보호, 변환, 모니터링하기 위한 서비스입니다. API gateways와 개발자 액세스를 관리하는 데 도움이 되지만, 인프라 프로비저닝 도구는 아닙니다. APIM 자체도 IaC로 배포할 수는 있으나, 서비스 자체가 각 비즈니스 유닛에 대해 20개의 Azure 리소스 표준 세트를 생성하는 것을 자동화하지는 않습니다.
Management groups는 subscriptions 위의 계층 구조를 제공하여 이를 구성하고 여러 subscriptions에 걸쳐 거버넌스 제어(Azure Policy, RBAC)를 적용합니다. 대규모에서 일관된 거버넌스에 매우 유용하지만, 리소스를 배포하지는 않습니다. 일반적으로 management groups는 거버넌스를 위해, templates는 자동화된 리소스 생성을 위해 함께 사용합니다.
문제 분석
핵심 개념:
이 문제는 대규모로 일관된 환경을 배포하는 데 사용되는 Infrastructure as Code (IaC) 및 Azure 거버넌스/관리 기능을 평가합니다. Azure에서 기본 네이티브 IaC 메커니즘은 Azure Resource Manager (ARM)이며, templates를 사용해 선언적으로 리소스를 배포합니다.
정답인 이유:
각 비즈니스 유닛이 동일한 20개의 Azure 리소스 세트를 필요로 하므로, 반복 가능하고 자동화되며 일관된 배포 방식이 필요합니다. Azure Resource Manager templates를 사용하면 여러 리소스(네트워크, 스토리지, VMs, 데이터베이스 등)의 원하는 상태를 JSON으로 정의하고 이를 하나의 단위(배포)로 배포할 수 있습니다. templates를 매개변수화(예: 비즈니스 유닛 이름, region, SKU, tags)하여 각 유닛이 동일한 아키텍처를 유닛별 값으로 배포받도록 할 수 있습니다. 이는 Azure Well-Architected Framework의 Operational Excellence(자동화, 반복성) 및 Reliability(일관되고 검증된 배포) 같은 원칙과 부합합니다.
주요 기능 / 모범 사례:
ARM templates는 parameters, variables, outputs, 그리고 모듈화(linked templates 또는 template specs)를 지원합니다. CI/CD pipelines(Azure DevOps/GitHub Actions)와 통합되며, 멱등(idempotent) 배포를 가능하게 합니다(templates를 다시 실행하면 선언된 상태로 수렴). 또한 Azure Policy로 표준을 강제하고 resource group/subscription 범위에서 RBAC를 적용할 수 있으며, templates는 리소스가 일관되게 생성되도록 보장합니다.
흔한 오해:
VM scale sets는 virtual machines의 확장만 자동화하며, 다양한 리소스 전체 세트를 생성하지는 않습니다. API Management는 APIs를 게시하고 보호하기 위한 것이지 인프라를 프로비저닝하는 것이 아닙니다. Management groups는 subscriptions를 구성하고 대규모로 거버넌스(policy/RBAC)를 적용하는 데 도움이 되지만, 리소스를 배포하지는 않습니다.
시험 팁:
“Azure 리소스 생성 자동화”, “동일한 리소스를 반복적으로”, “표준화된 배포”가 보이면 ARM templates(또는 ARM으로 컴파일되는 Bicep)를 떠올리세요. 여러 subscriptions에 걸쳐 subscriptions를 구성하거나 policy를 적용하는 것이 목적이면 management groups를 떠올리세요. compute 인스턴스 확장이 목적이면 VM scale sets를 떠올리세요.
4
문제 4
귀사는 Azure에 서버 배포를 자동화할 계획입니다.
관리자는 배포 중에 관리 자격 증명이 노출될 수 있다는 점을 우려하고 있습니다.
배포 중에 관리 자격 증명을 암호화하는 Azure 솔루션을 추천해야 합니다.
추천에 무엇을 포함해야 합니까?
Azure Key Vault는 secrets(passwords, tokens), cryptographic keys, certificates를 안전하게 저장하고 관리하도록 설계되었습니다. 자동화된 배포에서 templates와 pipelines는 Key Vault secrets를 참조할 수 있으므로 자격 증명이 code 또는 parameters에 plain text로 들어가지 않습니다. 액세스는 Entra ID, RBAC/access policies, managed identities를 통해 제어할 수 있어 least privilege와 auditability를 지원합니다.
Azure Information Protection (AIP)은 documents 및 emails를 분류, labeling, 보호(예: sensitivity labels 적용 및 rights management 강제)하기 위해 설계되었습니다. 인프라 자동화를 위한 배포 자격 증명을 저장하거나 안전한 secret retrieval을 제공하기 위한 용도가 아닙니다. 데이터 보호에는 도움이 되지만, 자동화된 서버 배포에서 admin credentials를 안전하게 주입(inject)하는 문제를 해결하지는 못합니다.
Azure Security Center(현재 Microsoft Defender for Cloud의 일부)는 security posture management, recommendations, 그리고 Azure 및 hybrid workloads에 대한 threat protection에 초점을 둡니다. misconfigurations 및 vulnerabilities에 대해 경고할 수는 있지만, 배포 중에 사용할 관리 자격 증명을 저장하고 암호화하는 메커니즘을 제공하지는 않습니다. Key Vault를 보완할 수는 있지만 secret management를 대체하지는 못합니다.
Azure Multi-Factor Authentication (MFA)은 추가 verification factors를 요구하여 사용자 sign-in을 강화합니다. Azure portal 및 administrative accounts에 대한 interactive access에는 유용하지만, 배포 자격 증명을 암호화하거나 저장하지 않으며, non-interactive automation이 secrets를 안전하게 가져오도록 돕지도 않습니다. 자동화된 배포는 일반적으로 MFA 기반의 interactive authentication이 아니라 service principals 또는 managed identities를 사용합니다.
문제 분석
핵심 개념:
이 문제는 Azure에서 자동화된 배포 중 비밀 정보(Secret)를 안전하게 관리하는지를 평가합니다. ARM templates, Bicep, Terraform, 또는 CI/CD pipelines를 통해 서버(VM)를 배포할 때는 종종 관리 자격 증명(passwords, SSH keys, tokens)이 필요합니다. 모범 사례는 secrets를 templates, scripts, 또는 pipeline variables에 plain text로 포함하지 않는 것입니다.
정답이 맞는 이유:
Azure Key Vault는 secrets, keys, certificates를 안전하게 저장하고 액세스를 제어하기 위한 Azure의 전용 서비스입니다. 배포 중에는 Key Vault secrets를 참조하여 관리 자격 증명이 source control, logs, 또는 deployment parameters에 노출되지 않고 runtime에 안전하게 가져오도록 할 수 있습니다. ARM templates와 Bicep는 parameters에 대한 Key Vault references(예: Key Vault secret URI 사용)를 지원하여 플랫폼이 secret을 안전하게 확인(resolve)할 수 있게 합니다. 이는 Azure Well-Architected Framework(Security pillar)의 원칙(민감 데이터 보호, 중앙 집중식 secret storage 사용, least privilege 적용)과 일치합니다.
주요 기능 및 모범 사례:
- Secrets management: VM admin passwords, SSH private keys(또는 더 나은 방법으로 SSH public keys를 저장하고 passwords를 피함), 그리고 기타 민감한 값을 저장합니다.
- Access control: Microsoft Entra ID (Azure AD)와 통합하고 RBAC 또는 Key Vault access policies를 사용하여 누가/무엇이 secrets를 읽을 수 있는지 제한합니다.
- Managed identities: credentials를 hardcoding하지 않고도 deployment automation(Azure DevOps, Azure의 GitHub Actions runners, 또는 Azure services)이 Key Vault에 액세스할 수 있도록 합니다.
- Auditing and governance: Azure Monitor/diagnostic settings를 통한 Key Vault logging은 secret access를 추적하는 데 도움이 됩니다.
- Encryption: secrets는 at rest에서 암호화되며, 요구 사항에 따라 Azure-managed keys 또는 customer-managed keys (CMK)로 보호됩니다.
흔한 오해:
MFA 또는 Defender for Cloud가 “자격 증명을 보호한다”고 생각할 수 있지만, 이러한 서비스는 authentication 강화 및 security posture management를 다루며 secret storage 및 배포에 대한 secure injection을 제공하지는 않습니다. Azure Information Protection은 documents/emails를 분류하고 보호하는 데 초점이 있으며, 배포 시점의 secret 처리와는 관련이 없습니다.
시험 팁:
AZ-900에서 passwords, connection strings, certificates, 또는 encryption keys를 안전하게 저장해야 하는 시나리오(특히 automation의 경우)가 나오면 Azure Key Vault를 선택하십시오. 문제가 “배포 중 자격 증명 암호화” 또는 “templates/pipelines에서 secrets 노출 방지”를 언급하면 Key Vault가 정석적인 정답입니다.
5
문제 5
(2개 선택)
Azure에 20TB의 데이터를 저장할 계획입니다. 해당 데이터는 드물게 액세스되며 Microsoft Power BI를 사용하여 시각화됩니다.
데이터에 대한 스토리지 솔루션을 추천해야 합니다.
어떤 두 가지 솔루션을 추천해야 합니까? 각 정답은 완전한 솔루션을 제시합니다.
참고: 각 정답 선택은 1점입니다.
Azure Data Lake(ADLS Gen2 기반)는 구조화/비구조화 데이터의 매우 큰 용량을 저비용으로 저장하는 데 이상적입니다. cool/archive tier와 lifecycle management를 통해 드문 액세스 패턴을 지원합니다. 분석 서비스와 통합되며, Power BI에 curated dataset을 제공하거나 Synapse/Databricks를 통해 공급하는 원시 데이터 리포지토리로 사용할 수 있습니다.
Azure Cosmos DB는 전 세계 분산형 NoSQL 데이터베이스로, 저지연·고처리량 운영 워크로드에 최적화되어 있습니다. 대량 데이터를 저장할 수는 있지만, 주로 BI 시각화를 목적으로 하는 20TB의 드문 액세스 데이터에 대해 일반적으로 가장 비용 효율적인 선택은 아닙니다. Power BI 시나리오는 보통 분석 스토어/warehouse를 사용합니다.
Azure SQL Data Warehouse(Azure Synapse Analytics dedicated SQL pool)는 대규모 분석 워크로드를 위해 설계되었고 Power BI와의 통합이 매우 강력합니다. MPP 아키텍처와 columnar storage를 사용하여 보고 및 대시보드를 위한 빠른 쿼리 성능을 제공합니다. TB 규모 데이터에 대해 관계형 분석 모델이 필요할 때 흔히 선택됩니다.
Azure SQL Database는 주로 OLTP 및 소규모~중간 규모의 분석 워크로드에 적합한 관리형 관계형 데이터베이스입니다. 20TB 및 BI 스타일 쿼리의 경우 dedicated data warehouse 솔루션보다 최적이 아닐 수 있으며, 비용이 더 들거나 확장이 더 어려울 수 있습니다. Power BI가 연결할 수는 있지만, 일반적인 TB 규모 warehouse 선택지는 아닙니다.
Azure Database for PostgreSQL은 관리형 오픈 소스 관계형 데이터베이스 서비스로, 일반적으로 트랜잭션 애플리케이션 및 범용 관계형 워크로드에 사용됩니다. 보고를 지원할 수는 있지만, Power BI를 위한 20TB 규모의 대규모 data warehousing에 특화되어 있지는 않습니다. 이 시나리오에는 보통 lake/warehouse 패턴이 더 적합합니다.
문제 분석
핵심 개념:
이 문제는 데이터 용량(20TB), 액세스 패턴(드문 액세스), 소비 도구(Power BI)를 기준으로 Azure 데이터 저장/분석 서비스를 선택하는지를 평가합니다. Azure 기본 관점에서는 적절한 데이터 플랫폼을 선택하는 것으로, 대규모 파일을 위한 data lake storage와 분석 쿼리 및 BI를 위한 data warehouse를 고르는 것입니다.
정답이 맞는 이유:
Azure Data Lake(Azure Data Lake Storage Gen2로 구현)는 TB~PB 규모의 매우 큰 데이터셋을 파일/오브젝트 형태로 저장하도록 설계되었으며, 저비용 티어와 lifecycle management를 제공하므로 데이터가 드물게 액세스되는 경우에 적합합니다. 원시/반정형 데이터(CSV, JSON, Parquet)의 landing zone으로 흔히 사용되며 big data analytics를 지원합니다.
Azure SQL Data Warehouse(현재 Azure Synapse Analytics dedicated SQL pool로 브랜딩됨)는 엔터프라이즈급 대규모 분석을 위해 특별히 설계되었습니다. Power BI와의 통합이 뛰어나 의미 체계 모델링과 빠른 대화형 대시보드를 제공합니다. 20TB의 분석 데이터에 대해 dedicated SQL pool은 columnar storage, MPP(massively parallel processing), BI 워크로드에 적합한 성능을 제공할 수 있습니다.
주요 기능 / 모범 사례:
- Data Lake Storage Gen2: hierarchical namespace, ACL, Azure AD와의 통합, lifecycle policy를 통해 데이터를 cool/archive tier로 이동하여 비용을 최적화(Well-Architected: Cost Optimization).
- Synapse dedicated SQL pool: 확장 가능한 compute(DWU), storage/compute 분리, columnstore index, 보고를 위한 강력한 Power BI 연결(Well-Architected: Performance Efficiency 및 Reliability).
- 일반적인 아키텍처: 원시 데이터를 Data Lake에 저장하고, 정제/변환한 뒤, BI를 위해 모델링된 데이터를 data warehouse로 로드.
흔한 오해:
Cosmos DB는 확장성이 매우 높지만, 저지연 운영형 NoSQL 워크로드에 최적화되어 있으며 Power BI용으로 20TB를 드물게 액세스하는 분석 시나리오에는 적합하지 않습니다. Azure SQL Database는 단일 관계형 데이터베이스 서비스로, 매우 큰 분석 규모에서는 dedicated warehouse에 비해 비용이 높거나 덜 적합할 수 있습니다. PostgreSQL은 OLTP 관계형 워크로드를 위한 것이며, 대규모 BI warehouse 용도가 아닙니다.
시험 팁:
AZ-900에서는 요구사항을 서비스 범주에 매핑하세요. “대규모 파일 + 드문 액세스”는 Data Lake/Storage tier를 가리키고, “Power BI 대규모 분석”은 data warehouse(Synapse)를 가리킵니다. TB 규모 분석이 보이면 OLTP 데이터베이스보다 warehouse/lake 패턴을 우선 고려하세요.
6
문제 6
귀사는 여러 대의 웹 서버와 여러 대의 데이터베이스 서버를 Azure에 배포할 계획입니다.
웹 서버에서 데이터베이스 서버로의 연결 유형을 제한하기 위한 Azure 솔루션을 권장해야 합니다.
권장 사항에 무엇을 포함해야 합니까?
Network security group (NSG)는 VNet 내 Azure 리소스로 들어오고 나가는 네트워크 트래픽을 필터링하는 Azure의 주요 메커니즘입니다. NSG에는 소스/대상 IP, 포트, 프로토콜을 기준으로 트래픽을 허용 또는 거부하는 우선순위가 있는 inbound 및 outbound security rule이 포함됩니다. 데이터베이스 서브넷/NIC에 NSG를 적용하면 웹-데이터베이스 연결을 필요한 포트(예: SQL)로만 제한하고 다른 모든 연결 유형을 차단할 수 있습니다.
Azure Service Bus는 애플리케이션을 분리하고 시스템을 비동기적으로 통합하는 데 사용되는 관리형 messaging 서비스(queues, topics/subscriptions)입니다. VM/서브넷 간 네트워크 연결을 제어하거나 필터링하지 않습니다. messaging 패턴을 사용하면 직접 연결의 필요성을 줄일 수는 있지만, 네트워크 계층에서 연결 유형을 제한하기 위한 네트워크 보안 제어가 아니므로 올바른 솔루션이 아닙니다.
local network gateway는 일반적으로 VPN gateway와 함께 site-to-site 또는 point-to-site 연결을 만들 때, 온프레미스 VPN 장치와 해당 주소 공간을 Azure에서 나타내는 리소스입니다. Azure의 웹 서버와 데이터베이스 서버 간 트래픽을 필터링하는 데 사용되지 않습니다. 하이브리드 시나리오에서도 Azure 내부에서 허용할 포트와 프로토콜을 제어하려면 여전히 NSG(또는 Azure Firewall)를 사용합니다.
route filter는 Azure ExpressRoute와 함께 사용되어 특정 Microsoft peering 서비스에 대해 어떤 BGP route를 광고/수신할지 제어합니다(예: 특정 Azure public service에 대한 액세스 제한). 이는 route 전파에 영향을 주며, 서브넷/VM 간 포트/프로토콜 수준의 액세스에는 영향을 주지 않습니다. “웹 계층에서 데이터베이스 계층으로 TCP 1433만 허용”과 같은 정책을 강제할 수 없으므로 연결 유형을 제한하는 데 적합하지 않습니다.
문제 분석
핵심 개념: 이 문제는 네트워크 계층에서 Azure 리소스 간 트래픽을 제어하고 제한하는 방법을 평가합니다. Azure에서 서브넷 및 네트워크 인터페이스로 들어오고 나가는 트래픽을 필터링하는 기본 제공 주요 기능은 Network Security Group (NSG)이며, 이는 stateful packet filter처럼 동작합니다.
정답인 이유: 웹 서버에서 데이터베이스 서버로의 연결 유형을 제한하려면(예: SQL에 대해 TCP 1433만 허용, RDP/SSH 차단, 특정 소스 서브넷으로 제한) NSG security rule을 사용합니다. 데이터베이스 서버가 있는 서브넷 및/또는 데이터베이스 VM의 NIC에 NSG를 연결할 수 있습니다. 그런 다음 웹 계층의 서브넷(또는 특정 IP 범위)에서 필요한 포트와 프로토콜만 허용하고 나머지는 모두 거부하는 inbound rule을 생성합니다. 이는 네트워크 세그먼테이션과 최소 권한을 강제하여 Azure Well-Architected Framework의 보안 원칙을 지원합니다.
주요 기능 및 모범 사례: NSG는 stateful(반환 트래픽은 자동으로 허용), 우선순위 기반 allow/deny rule 지원, service tag 및 application security group (ASG) 지원(예: 모든 웹 VM을 ASG에 넣고 rule에서 소스로 해당 ASG를 참조) 등의 기능을 제공합니다. 일반적인 설계는 웹과 데이터에 대해 별도의 서브넷을 둔 hub-and-spoke 또는 계층형 VNet이며, 각 계층 경계에 NSG를 적용합니다. 또한 가시성과 문제 해결을 위해 NSG flow log를 활성화할 수 있습니다.
흔한 오해: 일부 응시자는 messaging 서비스(Service Bus)를 네트워크 보안과 혼동하거나, routing 기능(route filter)이 포트/프로토콜을 제어한다고 생각합니다. Routing은 트래픽이 어디로 가는지를 결정할 뿐, 특정 TCP/UDP 연결이 허용되는지 여부를 결정하지는 않습니다.
시험 팁: “연결 유형 제한”, “포트 허용/거부”, “inbound/outbound 트래픽 제어”, “계층 분리”와 같은 표현이 보이면 NSG(그리고 경우에 따라 중앙집중식 L7/L4 검사를 위한 Azure Firewall)를 떠올리면 됩니다. AZ-900에서는 VNet 내 VM/서브넷 트래픽 필터링에 대한 기본 정답으로 NSG가 기대됩니다.
7
문제 7
Azure Information Protection은 무엇을 암호화할 수 있습니까?
오답입니다. 네트워크 트래픽 암호화는 일반적으로 TLS/SSL, VPN Gateway (IPsec/IKE), 암호화 옵션이 있는 Azure ExpressRoute, 또는 애플리케이션 수준 HTTPS와 같은 전송/보안 서비스에서 처리됩니다. Azure Information Protection은 네트워크 계층 암호화를 제공하지 않으며, 지속적 암호화 및 사용 권한을 통해 데이터 콘텐츠(파일/이메일)를 보호하는 데 초점을 둡니다.
정답입니다. Azure Information Protection은 Azure Rights Management를 사용하여 콘텐츠를 암호화하고 액세스/사용 제한을 강제하는 sensitivity label을 적용함으로써 문서 및 이메일 메시지를 암호화할 수 있습니다. 이 보호는 파일 또는 이메일이 어디로 이동하든 지속되어, 조직 내부 및 외부에서의 거버넌스, 규정 준수, 안전한 협업을 지원합니다.
오답입니다. Azure Storage 계정은 기본적으로 Microsoft-managed keys를 사용하는 Storage Service Encryption (SSE)로 암호화되며, 추가 제어를 위해 Azure Key Vault의 customer-managed keys를 사용할 수도 있습니다. AIP로 보호된 파일을 Storage 계정에 저장할 수는 있지만, AIP가 Storage 계정 리소스 자체를 암호화하는 것은 아닙니다.
오답입니다. Azure SQL Database 암호화는 data at rest를 위한 Transparent Data Encryption (TDE) 및 민감한 열을 end-to-end로 보호하는 Always Encrypted 같은 기능으로 제공됩니다. AIP는 Azure SQL database를 암호화하는 데 사용되지 않으며, 문서와 이메일의 정보 보호를 위해 설계되었습니다.
문제 분석
핵심 개념:
Azure Information Protection (AIP)은 데이터 분류, 레이블 지정, 보호 기능(현재는 주로 Microsoft Purview Information Protection 및 Azure Rights Management를 통해 제공됨)으로, 정보 자체—특히 파일과 이메일—를 레이블 적용 및 암호화/사용 권한 강제를 통해 보호하도록 설계되었습니다.
정답인 이유:
AIP는 콘텐츠와 함께 이동하는 보호를 적용하여 문서와 이메일 메시지를 암호화할 수 있습니다. 사용자가 암호화로 구성된 sensitivity label을 적용하면, AIP는 Rights Management (Azure RMS)를 사용하여 파일 또는 메시지를 암호화하고 액세스 제어(누가 열 수 있는지) 및 사용 제한(읽기 전용, 인쇄 금지, 전달 금지, 만료, 오프라인 액세스)을 강제합니다. 이는 네트워크나 인프라 리소스 수준이 아니라 콘텐츠 수준에서의 “data-at-rest 및 data-in-use” 보호입니다.
주요 기능 / 동작 방식:
- Sensitivity labels: 데이터를 분류(Public, Confidential, Highly Confidential)하고 선택적으로 암호화를 적용합니다.
- 권한 강제: 복사, 인쇄, 전달 같은 작업을 제한하고 만료를 설정합니다.
- 지속적 보호: 파일이 조직을 벗어나더라도(예: 외부로 이메일 전송 또는 USB 드라이브로 복사) 암호화가 유지되어 거버넌스 및 규정 준수 목표에 부합합니다.
- 통합: Microsoft 365 앱(Word, Excel, PowerPoint, Outlook)과 함께 작동하며, 조건에 따라 수동 또는 자동으로 적용할 수 있습니다.
흔한 오해:
많은 학습자가 AIP를 네트워크 암호화(TLS/VPN) 또는 스토리지/데이터베이스 암호화(Storage Service Encryption, TDE)와 혼동합니다. 이러한 기술은 전송 또는 특정 Azure 리소스를 보호합니다. AIP는 콘텐츠 자체를 보호하며 정보 거버넌스의 일부입니다.
시험 팁:
AZ-900에서 서비스가 무엇을 보호하는지 매핑하세요:
- AIP/Purview Information Protection = 문서/이메일(콘텐츠 수준 암호화 + 권한).
- 네트워크 트래픽 암호화 = TLS, VPN Gateway, ExpressRoute 암호화(옵션) (AIP 아님).
- Storage 계정 암호화 = SSE(Microsoft-managed 또는 customer-managed keys).
- SQL 암호화 = TDE, Always Encrypted. 질문에 “문서 및 이메일”이 언급되면 AIP를 떠올리세요.
8
문제 8
HOTSPOT -
Azure Cloud Shell을 사용하여 Azure를 관리해야 합니다.
어떤 Azure portal 아이콘을 선택해야 합니까? 답하려면, 답안 영역에서 적절한 아이콘을 선택하십시오.
핫 영역:
파트 1:
아래 이미지에서 올바른 항목을 선택하세요.
Pass: Azure Cloud Shell을 열기 위한 올바른 Azure portal 아이콘은 터미널/command prompt 아이콘(일반적으로 상단 바에 ">_"로 표시됨)입니다. 제공된 이미지에서는 portal 헤더의 오른쪽 상단 근처에 있는 ">_" 기호로 보입니다. 이 아이콘을 선택하면 portal 내의 창(pane)에서 Cloud Shell이 실행되며, 계정에 인증된 상태로 Azure CLI 또는 Azure PowerShell 명령을 실행할 수 있습니다.
다른 보이는 아이콘이 아닌 이유는 무엇인가요? 종(bell)은 Notifications, 톱니바퀴(gear)는 Settings, 물음표(question mark)는 Help, 스마일리(smiley)는 Feedback입니다. 대시보드 툴바에서 강조 표시된 "+"는 대시보드 보기에서 대시보드 타일/리소스를 추가하는 것과 관련이 있으며, Cloud Shell을 여는 기능이 아닙니다. 따라서 ">_" 아이콘을 선택하는 것이 Azure Cloud Shell을 사용하여 Azure를 관리하는 올바른 동작입니다.
9
문제 9
이 질문에서는 밑줄 친 텍스트가 올바른지 판단하기 위해 평가해야 합니다.
support.microsoft.com에서 Azure 지원 요청을 만들 수 있습니다.
지침: 밑줄 친 텍스트를 검토하십시오. 해당 텍스트가 문장을 올바르게 만든다면 No change is needed.를 선택하십시오. 문장이 올바르지 않다면 문장을 올바르게 만드는 답안을 선택하십시오.
변경이 필요 없다는 것은 틀렸습니다. 원래 문장은 support.microsoft.com에서 Azure support request를 생성할 수 있다고 말하지만, 이는 AZ-900에서 평가하는 표준 Azure support request 위치가 아닙니다. Azure support requests는 적절한 subscription 및 permissions와 연결될 수 있도록 Azure portal을 통해 생성됩니다. Microsoft에는 일반적인 support websites가 있지만, 이 시험 맥락에서 Azure support ticket 생성에 대한 기대되는 정답은 아닙니다. 따라서 이 문장은 변경되어야 합니다.
Azure portal은 Azure support request를 생성하는 올바른 장소입니다. Azure에서는 사용자가 일반적으로 Help + support에서 support ticket를 열며, 여기서 request는 올바른 subscription, billing account, 그리고 service context와 연결됩니다. 이 workflow는 또한 Azure RBAC와 support plan eligibility를 적용하는데, 이는 support case를 생성하고 관리하는 데 필수적입니다. AZ-900 시험 관점에서 Azure portal은 기대되는 정답이자 표준 정답입니다.
Knowledge Center는 Azure support requests를 생성하는 데 사용되지 않습니다. 이는 Azure subscriptions와 연결된 ticketing interface가 아니라 articles, troubleshooting guidance, 그리고 documentation를 위한 self-service 리소스입니다. 또한 service selection, severity, 그리고 subscription scoping을 포함하는 일반적인 Azure support request workflow를 제공하지 않습니다. 따라서 이 선택지는 문장을 틀리게 만듭니다.
Security & Compliance admin center는 Azure subscription support가 아니라 Microsoft 365 compliance 및 security administration과 관련이 있습니다. 이는 Azure service requests를 여는 것이 아니라 compliance policies, security settings, 그리고 관련 Microsoft 365 workloads를 관리하도록 설계되었습니다. Azure support cases는 Azure 전용 subscription context가 필요하며 Azure portal에서 처리됩니다. 따라서 이 선택지는 틀렸습니다.
문제 분석
핵심 개념: 이 문제는 Azure support request를 생성하는 올바른 위치를 묻습니다. Azure fundamentals에서 Azure subscriptions 및 services에 대한 support request는 Azure portal의 Help + support에서 생성합니다. 정답인 이유: Azure portal은 Azure support request를 열고 관리하기 위한 표준적이고 기대되는 인터페이스이며, subscriptions, billing scopes, 그리고 role-based access와 직접 연결되어 있습니다. 주요 기능: Azure support requests에는 적절한 subscription context, support plan, 그리고 Owner, Contributor, 또는 Support Request Contributor와 같은 permissions가 필요하며, 이 모든 것은 Azure portal에서 관리됩니다. 흔한 오해: 학습자들은 일반적인 Microsoft support websites나 documentation portals를 실제 Azure ticket 생성 workflow와 혼동하는 경우가 많습니다. 시험 팁: AZ-900에서 Azure support request를 어디에서 생성하는지 묻는다면, 문제가 명시적으로 다른 product-specific support center를 언급하지 않는 한 Azure portal을 선택하세요.
10
문제 10
Azure Advisor를 사용하여 수행할 수 있는 작업은 무엇입니까?
오답입니다. 온-프레미스 Active Directory를 Azure AD(Microsoft Entra ID)와 통합하는 작업은 Azure AD Connect(또는 cloud sync), federation(AD FS) 및 관련 ID 구성과 같은 ID 서비스 및 도구를 사용하여 수행합니다. Azure Advisor는 디렉터리 통합을 수행하지 않으며, 기존 Azure 리소스를 분석하고 최적화 권장 사항만 제공합니다.
오답입니다. Azure 솔루션의 비용을 추정하는 작업은 일반적으로 Azure Pricing Calculator(배포 전 추정) 및 Total Cost of Ownership(TCO) Calculator(온-프레미스 vs Azure 비교)로 수행합니다. Azure Advisor는 이미 Azure에서 실행 중인 리소스에 대해 크기 조정 또는 사용률이 낮은 리소스 종료와 같은 조치를 권장하여 비용을 최적화하는 데 초점을 둡니다.
정답입니다. Azure Advisor는 모범 사례에 따라 Azure 환경을 검증하고 개선하는 데 도움이 되는 보안(Security) 권장 사항을 제공합니다. 구성 및 보안 상태(posture) 개선 사항(예: 보안 제어 강화 및 노출 감소)을 식별하고 수정(remediation)을 안내합니다. 이는 거버넌스 및 Azure Well-Architected Framework의 보안(Security) 기둥과 일치합니다.
오답입니다. 어떤 온-프레미스 리소스를 Azure로 마이그레이션할 수 있는지 평가하는 목적은 Azure Migrate에 있습니다. Azure Migrate는 검색(discover), 평가(assess), 마이그레이션 계획(servers, databases, apps)을 지원합니다. Azure Advisor는 온-프레미스 환경을 인벤토리화하거나 마이그레이션 준비 상태 평가를 수행하지 않으며, 기존 Azure 배포의 최적화에 초점을 둡니다.
문제 분석
핵심 개념:
Azure Advisor는 개인화된 클라우드 컨설턴트로, Azure 리소스 구성과 사용 원격 분석을 분석한 다음 신뢰성(Reliability), 보안(Security), 비용(Cost), 운영 우수성(Operational Excellence), 성능(Performance)과 같은 주요 범주 전반에 걸쳐 권장 사항을 제공합니다. 이는 모범 사례에 따라 환경을 지속적으로 개선하는 데 도움이 되므로 Azure 관리 및 거버넌스의 일부입니다.
정답인 이유:
옵션 C가 정답인 이유는 Azure Advisor에 보안(Security) 권장 사항이 포함되어 있어 Azure 구독 및 리소스가 보안 모범 사례를 따르는지 확인(및 개선)하는 데 도움이 되기 때문입니다. Advisor는 누락된 네트워크 보안 제어, 과도하게 허용적인 액세스, 암호화 부족 또는 안전하지 않은 구성 등과 같은 문제 및 기타 보안 상태(posture) 관련 개선 사항을 표시합니다. Microsoft Defender for Cloud가 고급 보안 상태 관리의 주요 서비스이지만, Advisor는 접근하기 쉬운 중앙 집중식 권장 사항 엔진으로서 모범 사례에 부합하는 보안 지침을 포함합니다.
주요 기능:
Advisor 권장 사항은 우선순위가 지정되고 실행 가능하며, 종종 수정(remediate)을 위해 구성 블레이드로 직접 연결됩니다. 권장 사항은 구독, 리소스 그룹, 범주, 영향도별로 필터링할 수 있습니다. 또한 적용되지 않는 권장 사항에 대해 억제(suppression)/해제(dismissal)를 구성할 수 있습니다. Advisor는 최소 권한, 안전한 네트워킹, 개선된 거버넌스 위생을 장려함으로써 Azure Well-Architected Framework 원칙—특히 보안(Security) 및 운영 우수성(Operational Excellence)—과 통합됩니다.
일반적인 오해:
많은 학습자가 Advisor를 Azure Pricing Calculator(배포 전 비용 추정) 및 Azure Migrate(평가 및 마이그레이션 계획)와 혼동합니다. 또한 보안 모범 사례 검증은 Defender for Cloud에서만 수행된다고 가정하는 경우가 있지만, Advisor도 보안 권장 사항을 제공하긴 합니다(다만 Defender for Cloud가 더 깊고 포괄적입니다).
시험 팁:
AZ-900에서는 다음의 빠른 매핑을 기억하세요:
- Azure Advisor = 배포된 Azure 리소스를 최적화하기 위한 권장 사항(비용, 보안, 신뢰성, 성능, 운영 우수성).
- Pricing Calculator = 배포 전에 비용을 추정.
- Azure Migrate = 온-프레미스 워크로드를 평가/마이그레이션.
- Azure AD/Entra ID 도구 = ID 통합이며 Advisor가 아님.
질문에서 기존 구독/리소스에 대한 “모범 사례”와 “권장 사항”이 언급되면 Azure Advisor를 떠올리세요.
