50개 문제와 45분 시간 제한으로 실제 시험을 시뮬레이션하세요. AI 검증 답안과 상세 해설로 학습하세요.
AI 기반
모든 답안은 3개의 최고 AI 모델로 교차 검증하여 최고의 정확도를 보장합니다. 선택지별 상세 해설과 심층 문제 분석을 제공합니다.
웹 애플리케이션을 Azure로 마이그레이션할 계획입니다. 해당 웹 애플리케이션은 외부 사용자가 액세스합니다. 웹 애플리케이션을 관리하는 데 사용되는 관리 노력을 최소화하기 위해 클라우드 배포 솔루션을 권장해야 합니다. 권장 사항에 무엇을 포함해야 합니까?
SaaS는 공급자가 관리하는 완전한 즉시 사용 가능한 애플리케이션(예: Microsoft 365)을 제공합니다. 관리 부담을 가장 많이 줄여주지만, 일반적으로 사용자 지정 웹 애플리케이션 코드를 그대로 배포할 수는 없으며, 사용자의 애플리케이션을 호스팅하는 대신 공급업체의 애플리케이션을 채택하는 형태가 됩니다. 기존 사용자 지정 웹 앱을 마이그레이션하는 경우, 앱을 완전히 대체하는 상황이 아니라면 SaaS는 보통 적합하지 않습니다.
PaaS는 관리 노력을 최소화하면서 자체 웹 애플리케이션을 마이그레이션하고 호스팅하는 데 가장 적합합니다. Azure App Service 같은 서비스는 서버, OS 패치, 그리고 런타임 유지 관리의 상당 부분을 관리하지 않고도 코드를 배포할 수 있게 해줍니다. 애플리케이션과 구성은 사용자가 제어하지만, Microsoft가 기반 플랫폼을 관리하므로 더 쉬운 스케일링, 고가용성 옵션, 통합 모니터링 및 보안 기능을 활용할 수 있습니다.
IaaS(virtual machines)는 가장 많은 제어를 제공하며 lift-and-shift 마이그레이션에 흔히 사용되지만, 가장 많은 관리가 필요합니다. OS, 패치, 웹 서버/런타임 구성, 스케일링 설정, 백업, 그리고 지속적인 유지 관리를 사용자가 책임져야 합니다. 요구 사항이 관리 노력 최소화이므로, IaaS는 주요 서비스 모델 중 일반적으로 가장 부적합한 선택입니다.
DaaS(Database as a Service)는 공급자가 데이터베이스 인프라와 많은 유지 관리 작업을 관리하는 관리형 데이터베이스 제공 서비스(예: Azure SQL Database, Azure Cosmos DB)를 의미합니다. DaaS는 데이터베이스 관리 부담을 줄일 수 있지만, 웹 애플리케이션 자체를 호스팅하는 문제를 해결하지는 않습니다. 웹 계층을 위해서는 여전히 PaaS 또는 IaaS와 같은 compute/hosting 모델이 필요합니다.
핵심 개념: 이 문제는 클라우드 서비스 모델(IaaS, PaaS, SaaS)과 이들이 운영 책임에 어떤 영향을 미치는지 평가합니다. AZ-900에서 “관리 노력 최소화”는 일반적으로 클라우드 공급자가 기반 플랫폼의 대부분을 관리하면서도 사용자가 자체 애플리케이션을 배포할 수 있는 모델을 선택하는 것을 의미합니다. 정답인 이유: Platform as a Service (PaaS)는 서버, 운영 체제, 그리고 런타임 패치의 상당 부분을 관리하지 않고 애플리케이션을 호스팅하도록 설계되었습니다. 외부 사용자가 액세스하는 웹 애플리케이션의 경우 Azure App Service (Web Apps)와 같은 PaaS 제공 서비스가 흔한 권장 사항입니다. App Service를 사용하면 Microsoft가 인프라, OS 업데이트, 많은 플랫폼 패치를 관리하고, 기본 제공 기능(스케일링, SSL 바인딩, 배포 슬롯)을 제공하므로 VM을 실행하는 것에 비해 관리 오버헤드가 크게 줄어듭니다. 주요 기능 및 모범 사례: Azure에서의 PaaS 웹 호스팅은 일반적으로 기반 OS의 자동 패치, 기본 제공 로드 밸런싱, autoscale, 모니터링 통합(Azure Monitor/Application Insights), 그리고 간소화된 CI/CD 통합(GitHub Actions/Azure DevOps)을 포함합니다. Azure Well-Architected Framework 관점에서 PaaS는 Operational Excellence(반복 작업 감소, 표준화된 배포), Reliability(HA 옵션이 있는 관리형 플랫폼), Security(관리형 패치, Entra ID 통합, 관리형 인증서, 해당 시 private endpoints)를 향상시킵니다. 흔한 오해: SaaS는 가장 낮은 관리 노력처럼 들릴 수 있지만, SaaS는 공급자가 제공하는 완성된 애플리케이션(예: Microsoft 365, Dynamics 365)을 소비하는 모델입니다. 이 시나리오는 사용자가 소유한 “웹 애플리케이션”을 마이그레이션하는 것이므로, 공급업체의 완제품으로 대체하는 것이 아니라 호스팅 플랫폼이 필요합니다. IaaS(VM)는 lift-and-shift에 자주 선택되지만 가장 많은 관리가 필요합니다(OS 패치, 웹 서버 구성, 스케일링, 백업). “DaaS”는 웹 앱 호스팅에 적합한 모델이 아니며, 관리형 데이터베이스 서비스를 의미합니다. 시험 팁: 자체 앱을 호스팅하면서 “관리 노력 최소화”가 나오면 PaaS를 떠올리세요. “코드 없이/완성된 애플리케이션 소비”라면 SaaS입니다. “최대 제어/사용자 지정 OS”라면 IaaS입니다. 또한 “web app hosting” 같은 표현은 Azure App Service (PaaS)로 강하게 매핑됩니다.
이동 중에도 모든 문제를 풀고 싶으신가요?
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
이동 중에도 모든 문제를 풀고 싶으신가요?
무료 앱 받기
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
이 질문에서는 밑줄 친 텍스트가 올바른지 평가해야 합니다.
Resource groups는 조직이 여러 구독 전반에서 Azure 리소스의 규정 준수를 관리할 수 있는 기능을 제공합니다.
지침: 밑줄 친 텍스트를 검토하십시오. 해당 문장을 올바르게 만든다면 변경할 필요 없음을 선택하십시오. 문장이 올바르지 않다면 문장을 올바르게 만드는 답안을 선택하십시오.
“변경할 필요 없음”은 Resource groups가 여러 구독에 걸친 규정 준수 관리를 제공하지 않기 때문에 틀립니다. Resource group은 단일 구독 범위로 제한되며 주로 리소스를 구성하고, 해당 범위에서 RBAC를 적용하고, 배포 및 삭제 같은 수명 주기 작업을 관리하기 위한 것입니다. Resource group 수준에서 태그를 지정하고 액세스를 제어할 수는 있지만, 이는 규정 준수 규칙을 정의하고 강제하는 것과는 다릅니다. 구독 간 규정 준수에는 적절한 범위에 적용된 Azure Policy 같은 거버넌스 서비스가 필요합니다.
Management groups는 구독을 계층 구조로 구성하고 여러 구독에 걸쳐 Azure Policy 및 RBAC 같은 거버넌스 제어를 적용하기 위한 범위를 제공합니다. 그러나 Management groups 자체가 규정 준수 규칙을 정의하거나 강제하지는 않으며, 컨테이너/범위 역할을 합니다. 실제로 규정 준수를 관리하려면 Management group 범위에 Azure Policy(또는 initiatives)를 할당해야 합니다. 따라서 텍스트를 “Management groups”로 바꾸는 것은 불완전하며 규정 준수 강제 측면에서 기술적으로 부정확합니다.
Azure Policy는 규정 준수를 위해 리소스 구성을 강제하거나 감사하는 정책을 만들고, 할당하고, 관리하는 데 사용되는 Azure 거버넌스 서비스입니다. 정책은 여러 구독과 그 리소스를 일관되게 포괄하도록 (관리 그룹 또는 구독과 같은) 광범위한 범위에 할당할 수 있습니다. 규정 준수 보고를 제공하며 Deny 같은 effect를 사용해 비준수 배포를 방지하거나 Modify/DeployIfNotExists로 수정할 수 있습니다. 이는 여러 구독에 걸쳐 있는 Azure 리소스 전반의 규정 준수를 관리해야 한다는 요구 사항과 직접적으로 일치합니다.
Azure App Service plans는 웹 앱, API, functions를 호스팅하기 위한 컴퓨팅 및 가격 책정 구성 요소로, 지역, SKU, 확장 특성을 정의합니다. 이는 거버넌스, 규정 준수 평가 또는 리소스/구독 전반에서 구성 표준을 강제하는 것과는 관련이 없습니다. App Service plans는 App Service 워크로드에만 적용되며 정책 기반 규정 준수 제어를 제공하지 않습니다. 이 시나리오는 규정 준수 관리에 관한 것이며, 이는 호스팅 플랜이 아니라 Azure Policy로 해결합니다.
핵심 개념: 이 질문은 Azure 거버넌스 및 규정 준수 도구에 대한 이해—특히 여러 구독에 걸쳐 리소스 전반의 규정 준수를 관리하고 강제하는 데 사용되는 Azure 구성 요소가 무엇인지—를 테스트합니다. 정답이 맞는 이유: Resource groups는 주로 단일 구독 내에서 Azure 리소스를 구성하고 관리(수명 주기, RBAC 범위 지정, 태깅)하기 위한 논리적 컨테이너입니다. Resource groups 자체만으로는 여러 구독에 걸친 규정 준수 강제를 제공하지 않습니다. Azure Policy는 규칙(정책 정의)을 정의하고 관리 그룹, 구독, Resource groups를 포함한 범위에서 규정 준수를 강제/평가(정책 할당)하도록 설계된 거버넌스 서비스입니다. 따라서 “Resource groups”를 “Azure policies”로 바꾸면 문장이 올바르게 됩니다. 주요 기능 / 구성: - Azure Policy definitions: 허용/거부 구성(예: 허용 위치, 필수 태그, 허용 SKU)을 설명하는 JSON 규칙. - Policy assignments and scope: 관리 그룹, 구독, Resource groups 또는 리소스 수준 범위에서 정책을 할당하여 규정 준수를 평가/강제. - Effects: Deny, Audit, Append, Modify, DeployIfNotExists(강제 vs. 보고 vs. 수정). - Initiatives(정책 세트): 여러 정책을 그룹화하여 대규모로 규정 준수 프레임워크를 관리. - Compliance reporting and remediation tasks: 규정 준수 상태를 확인하고 비준수 리소스를 수정(Modify/DeployIfNotExists의 경우 종종 managed identity 사용). 흔한 오해: - Resource groups(조직/수명 주기 경계)와 거버넌스/규정 준수 강제(Azure Policy)를 혼동. - Management groups가 직접 “규정 준수”를 제공한다고 가정; Management groups는 거버넌스 도구를 적용하기 위한 계층 및 범위를 제공하지만, 규정 준수 규칙은 Azure Policy에서 옴. - Azure Policy와 RBAC를 혼동: RBAC는 누가 무엇을 할 수 있는지 제어하고, Policy는 어떤 구성이 허용되는지 제어. 시험 팁: - Azure Policy = 구성 규정 준수 강제/평가(Deny/Audit/Modify/DeployIfNotExists). - Management groups = 구독을 구성하고 여러 구독에 걸쳐 Policy/RBAC를 적용하기 위한 범위를 제공. - Resource groups = 구독 내 리소스를 구성; RBAC 범위 지정 및 수명 주기 관리에 유용하지만, 구독 간 규정 준수에는 해당하지 않음. - 질문에 “compliance”가 나오면 Resource groups가 아니라 Azure Policy(그리고 경우에 따라 Blueprints/Defender for Cloud)를 떠올릴 것.
어떤 Azure 지원 플랜에서 새 지원 요청을 열 수 있나요?
오답입니다. Premier와 Professional Direct는 support requests를 허용하지만, 그것들만 가능한 것은 아닙니다. Developer와 Standard도 technical support request 기능을 포함하므로, 이 선택지는 너무 좁습니다. 이는 가장 높은 enterprise tiers만 case를 열 수 있다는 오해를 반영합니다. Azure support request access는 최상위 tiers에서만이 아니라 Developer부터 시작합니다.
오답입니다. 이 선택지는 Standard, Professional Direct, Premier를 포함하지만 Developer를 빠뜨렸습니다. Developer는 유료 Azure support plan이며, 상위 tiers보다 response targets는 느리지만 technical support requests를 제출할 수 있는 기능을 포함합니다. Developer가 없으므로 이 선택지는 불완전합니다. 시험에서는 Developer 이상 모든 유료 plans가 case creation을 지원한다는 점을 알아야 합니다.
정답입니다. Developer, Standard, Professional Direct, Premier는 고객이 technical issues에 대해 support requests를 열 수 있게 하는 Azure support plans입니다. 이들은 유료 support tiers이며, 주로 response times, advisory features, 제공되는 support 범위에서 차이가 있습니다. Basic에는 technical support가 포함되지 않으므로 정답 선택지에서 제외되어야 합니다. AZ-900에서 어떤 support plans가 support request를 열 수 있게 하는지 묻는 경우, 기대되는 정답은 Developer부터 시작하는 유료 plans의 집합입니다.
오답입니다. 이 선택지는 Basic을 잘못 포함하고 있습니다. Basic은 documentation, community resources, billing/subscription support에 대한 access를 제공하지만, AZ-900에서 일반적으로 테스트되는 support-plan 비교에서는 Azure technical support request 기능을 포함하지 않습니다. 따라서 Basic을 포함하면 이 선택지는 너무 넓습니다. 올바른 기준선은 technical support가 Basic이 아니라 Developer부터 시작한다는 것입니다.
핵심 개념: 이 문제는 Azure support plans에 대한 지식과 어떤 plan이 Azure services에 대한 support request를 생성할 수 있게 하는지를 테스트합니다. AZ-900에서 Microsoft는 무료 Basic plan과 technical support requests를 제출할 수 있는 기능이 포함된 유료 support plans를 구분합니다. 정답은 Developer, Standard, Professional Direct, Premier를 포함하지만 Basic은 제외하는 선택지입니다. 흔한 오해는 billing 및 subscription help가 존재하므로 Basic도 해당된다고 가정하는 것이지만, Azure support plans에 대한 시험 문제는 일반적으로 technical support request 기능을 의미합니다. 시험 팁: Basic < Developer < Standard < Professional Direct < Premier 순서를 기억하고, technical support는 Basic이 아니라 Developer부터 시작한다는 점을 기억하세요.
HOTSPOT - Azure portal에서 다음 작업을 수행하는 데 사용해야 하는 블레이드를 식별해야 합니다: ✑ 보안 권장 사항 보기. ✑ Azure 서비스의 상태 모니터링. ✑ 사용 가능한 가상 머신 이미지 찾아보기. 각 작업에 대해 어떤 블레이드를 식별해야 합니까? 답하려면 답안 영역에서 적절한 옵션을 선택하십시오. 참고: 각 정답 선택은 1점입니다. 핫 영역:
Azure 서비스의 상태를 모니터링합니다:
정답: A (Monitor). Azure 서비스의 상태를 모니터링하는 작업은 Service Health 기능을 포함하는 Azure Monitor 블레이드를 통해 수행됩니다. Azure Service Health는 서비스 이슈, 계획된 유지 관리, 그리고 구독 및 리전에 영향을 줄 수 있는 상태 권고(health advisories)에 대한 가시성을 제공합니다. 이는 운영 모니터링 기능(관찰, 감지, 대응)이며, 이는 Azure Monitor가 설계된 목적과 정확히 일치합니다. 다른 선택지가 틀린 이유: - B (Subscriptions)는 구독 수준의 관리(액세스 제어, 정책, 비용 관리 진입점)를 위한 것이며, 플랫폼 인시던트를 추적하기 위한 것이 아닙니다. - C (Marketplace)는 솔루션/이미지를 검색하고 배포하기 위한 것이며, 상태 모니터링을 위한 것이 아닙니다. - D (Advisor)는 권장 사항(신뢰성 가이던스 포함)을 제공하지만, 실시간 서비스 상태 및 인시던트 추적을 위한 기본 블레이드 역할을 하지는 않습니다.
사용 가능한 가상 머신 이미지 찾아보기:
정답: C (Marketplace). 사용 가능한 가상 머신 이미지를 찾아보는 작업은 Azure Marketplace를 통해 수행합니다. Marketplace는 VM 이미지(예: Windows Server, Ubuntu, Red Hat 및 다양한 타사 어플라이언스)를 포함한 Microsoft 및 파트너 제공 항목의 카탈로그입니다. VM을 생성할 때 이미지 선택 환경은 Marketplace 목록을 기반으로 합니다. 다른 선택지가 틀린 이유: - A (Monitor)는 메트릭, 로그, 경고 및 서비스 상태를 위한 것이며, 배포 가능한 이미지를 선택하는 용도가 아닙니다. - B (Subscriptions)는 구독 범위와 설정을 관리하며, 이미지 카탈로그를 제공하지 않습니다. - D (Advisor)는 최적화 및 모범 사례 권장 사항(비용, 보안, 안정성, 성능, 운영 우수성)을 제공하며, VM 이미지를 찾아보는 경험을 제공하지 않습니다.
보안 권장 사항 보기:
정답: D (Advisor). 보안 권장 사항을 확인하는 것은 Azure Advisor의 핵심 기능으로, Advisor는 Security를 포함한 여러 범주에 걸쳐 가이드를 제공합니다. Advisor 권장 사항은 보안 상태를 개선하는 데 도움이 됩니다(예: MFA 활성화, NSG 규칙을 적절히 적용, 리소스 구성 개선). 이는 실행 가능한 개선 사항을 식별함으로써 Azure Well-Architected Framework 가이드와도 일치합니다. 다른 선택지가 틀린 이유: - A (Monitor)는 텔레메트리와 상태/경고에 초점을 맞추며, 처방형 보안 권장 사항을 제공하는 것이 아닙니다. - B (Subscriptions)는 관리 범위 관리이며 보안 권장 사항을 생성하지 않습니다. - C (Marketplace)는 솔루션과 이미지의 카탈로그로, 배포된 리소스를 분석하여 보안 권장 사항을 생성하지 않습니다. 참고: 더 넓은 Azure 범위에서 Microsoft Defender for Cloud도 보안 상태 권장 사항의 주요 출처이지만, 제시된 선택지 중에서는 Advisor가 올바른 블레이드입니다.
DRAG DROP - Azure 서비스를 올바른 정의와 매칭하세요. 지침: 답하려면 왼쪽 열에서 적절한 Azure 서비스를 오른쪽의 설명으로 끌어다 놓으세요. 각 서비스는 한 번만, 여러 번, 또는 전혀 사용하지 않을 수 있습니다. 참고: 각 정답 선택은 1점입니다. 선택 및 배치:
serverless 코드를 위한 플랫폼을 제공합니다
정답: B. Azure Functions. Azure Functions는 트리거(HTTP 요청, 타이머, 큐 메시지, Event Grid 이벤트 등)에 대한 응답으로 코드를 실행하기 위한 Azure의 serverless compute 서비스입니다. 서버를 프로비저닝하거나 관리하지 않으며, 확장은 플랫폼에서 처리되고, 요금은 일반적으로 사용량 기반(실행 횟수 및 사용된 리소스에 따라 과금)으로 책정되는데, 이는 serverless의 핵심 특징입니다. 다른 선택지가 틀린 이유: A. Azure Databricks는 Apache Spark 기반의 빅데이터 분석 및 ML 플랫폼이며, 일반적인 serverless 코드 런타임이 아닙니다. C. Azure App Service는 관리형 인프라에서 웹 앱/API를 호스팅하기 위한 PaaS이지만, “serverless 코드”를 위한 주요 플랫폼은 아닙니다. D. Azure Application Insights는 모니터링/telemetry 및 진단을 위한 서비스이며, 코드를 실행하는 서비스가 아닙니다.
machine learning을 위한 빅데이터 분석 서비스
정답: A. Azure Databricks. Azure Databricks는 Apache Spark에 최적화된 관리형 분석 플랫폼으로, 대규모 빅데이터 처리, data engineering, 그리고 확장 가능한 machine learning에 일반적으로 사용됩니다. Azure storage 서비스(예: ADLS Gen2)와 통합되며, 협업형 notebook, ML library, 그리고 확장 가능한 cluster를 지원하므로 “machine learning을 위한 빅데이터 분석 서비스”에 가장 적합합니다. 다른 선택지가 틀린 이유: B. Azure Functions는 이벤트 기반 serverless compute용이며, 빅데이터 분석 엔진이 아닙니다. C. Azure App Service는 web application과 API를 호스팅하며, 분산 빅데이터 처리를 위해 설계되지 않았습니다. D. Azure Application Insights는 애플리케이션 모니터링 및 진단을 제공하며, 분석/ML 처리가 아닙니다.
웹 앱에서 이상 징후를 감지하고 진단합니다
정답: D. Azure Application Insights. Application Insights는 Azure Monitor 내의 APM 기능으로, 애플리케이션(요청, 종속성, 예외, 성능 카운터, 추적)에서 텔레메트리를 수집하고 문제를 감지, 조사, 진단하는 데 도움을 줍니다. 스마트 감지(자동 이상 감지), 애플리케이션 맵, 분산 추적, 엔드 투 엔드 트랜잭션 진단과 같은 기능을 지원하여 “웹 앱에서 이상 징후를 감지하고 진단”한다는 설명과 직접적으로 일치합니다. 다른 선택지가 틀린 이유: A. Azure Databricks는 데이터 분석 및 ML에 초점을 맞추며, 웹 앱 이상 감지에 초점을 맞추지 않습니다. B. Azure Functions는 서버리스 코드를 실행합니다. 로그/텔레메트리를 내보낼 수는 있지만, 이상 감지/진단 플랫폼 자체를 제공하지는 않습니다. C. Azure App Service는 웹 앱을 호스팅하지만, 모니터링/이상 감지는 App Service 단독이 아니라 Application Insights 같은 도구에서 제공됩니다.
웹 앱을 호스팅함
정답: C. Azure App Service. Azure App Service는 웹 앱, REST APIs, 모바일 백엔드를 호스팅하기 위한 완전 관리형 PaaS입니다. 배포 슬롯, 자동 확장, 사용자 지정 도메인, TLS/SSL, 인증/권한 부여 통합, 여러 런타임(예: .NET, Java, Node.js, Python) 지원과 같은 기본 제공 기능을 제공합니다. 이는 “웹 앱을 호스팅함”과 정확히 일치합니다. 다른 선택지가 틀린 이유: A. Azure Databricks는 분석/ML 플랫폼이며, 웹 호스팅 서비스가 아닙니다. B. Azure Functions는 HTTP 트리거 엔드포인트를 노출할 수 있지만, 일반적인 웹 앱 호스팅 플랫폼이라기보다는 주로 서버리스 함수입니다. D. Azure Application Insights는 애플리케이션을 모니터링하며, 호스팅하지는 않습니다.
귀사는 여러 개의 사용자 지정 애플리케이션을 Azure에 배포할 계획입니다. 해당 애플리케이션은 회사 고객에게 청구서 발행 서비스를 제공할 것입니다. 각 애플리케이션에는 여러 개의 사전 요구 애플리케이션과 서비스가 설치되어야 합니다. 모든 애플리케이션에 대한 클라우드 배포 솔루션을 추천해야 합니다. 무엇을 추천해야 합니까?
SaaS는 인터넷을 통해 제공되는 완전한 벤더 관리형 애플리케이션(예: Microsoft 365)입니다. SaaS 제공 서비스에 자체 사용자 지정 애플리케이션을 배포하는 것이 아니라, 단지 구성하고 사용합니다. 요구 사항이 사전 요구 사항이 있는 여러 사용자 지정 청구서 발행 애플리케이션을 배포하는 것이므로, SaaS는 시나리오에 맞지 않습니다. SaaS는 관리를 최소화하지만, 기본 플랫폼과 소프트웨어 스택에 대한 제어도 가장 적습니다.
PaaS는 관리형 애플리케이션 플랫폼(예: Azure App Service)을 제공하며, 사용자는 코드를 배포하고 Azure가 OS와 런타임의 상당 부분을 관리합니다. PaaS는 애플리케이션이 지원되는 프레임워크에 맞고 사용자 지정 OS 수준 사전 요구 사항을 설치할 필요가 없을 때 이상적입니다. 그러나 이 문제는 여러 사전 요구 애플리케이션과 서비스 설치를 강조하며, 이는 종종 OS 액세스와 사용자 지정 설치 프로그램이 필요하므로 PaaS는 이 요구 사항에 덜 적합합니다.
IaaS(예: Azure Virtual Machines)는 사전 요구 애플리케이션과 서비스를 설치 및 관리해야 하고, OS를 제어하며, 전체 소프트웨어 스택을 사용자 지정해야 할 때 가장 적합합니다. 이는 여러 종속성이 있는 사용자 지정 청구서 발행 애플리케이션을 배포하는 시나리오와 일치합니다. IaaS를 사용하면 사용자 지정 이미지와 자동화를 통해 배포를 표준화할 수 있으며, PaaS에서 지원되지 않을 수 있는 레거시 구성 요소나 특수 미들웨어에 대한 유연성도 유지할 수 있습니다.
핵심 개념: 이 문제는 클라우드 서비스 모델(SaaS, PaaS, IaaS)과 책임 경계 및 배포 요구 사항에 따라 각각을 언제 선택해야 하는지를 평가합니다. 정답인 이유: 시나리오는 여러 개의 사용자 지정 애플리케이션을 배포하는 것이며, 각 애플리케이션에 설치해야 하는 여러 사전 요구 애플리케이션과 서비스가 있습니다. 이러한 요구 사항은 운영 체제, 런타임, 미들웨어에 대한 최대 수준의 제어와 필요한 종속성을 정확히 설치 및 관리할 수 있는 능력이 필요함을 강하게 시사합니다. Infrastructure as a Service (IaaS)(예: Azure Virtual Machines)는 이러한 유연성을 제공합니다. 즉, 컴퓨팅, 스토리지, 네트워킹을 프로비저닝한 다음 OS, 애플리케이션 스택, 사전 요구 사항을 설치하고 구성합니다. 이는 특정 종속성 버전에 맞춰 플랫폼을 구성해야 하거나 OS 수준 액세스로 설치 프로그램과 서비스가 실행되어야 하는 “lift-and-shift” 또는 “custom stack” 배포에 부합합니다. 주요 기능 및 모범 사례: Azure IaaS에서는 VM 이미지(Marketplace, 사용자 지정 이미지 또는 Azure Compute Gallery)를 사용해 빌드를 표준화할 수 있으며, ARM/Bicep, Terraform 또는 VM extensions/Desired State Configuration 같은 자동화 도구를 사용해 사전 요구 사항을 일관되게 설치할 수 있습니다. 확장성과 복원력을 위해 Availability Sets 또는 Virtual Machine Scale Sets를 사용할 수 있고, 가능한 경우 Availability Zones에 걸쳐 VM을 배치할 수 있습니다. Azure Well-Architected Framework 관점에서 IaaS는 더 많은 운영 우수성(패치, 모니터링, 백업)이 필요하지만, 종속성이 복잡할 때 신뢰성과 보안 요구 사항을 충족하기 위한 제어 권한을 제공합니다. 일반적인 오해: PaaS는 관리 오버헤드를 줄이기 때문에 사용자 지정 앱에 자주 선호되지만, PaaS는 일반적으로 OS 수준 사용자 지정을 제한하며 임의의 사전 요구 설치 프로그램/서비스를 지원하지 못할 수 있습니다. SaaS는 완성된 애플리케이션을 소비하는 형태이며, 자체 사용자 지정 애플리케이션을 배포하는 대상이 아니므로 가장 적합하지 않습니다. 시험 팁: “사용자 지정 애플리케이션”과 “여러 사전 요구 애플리케이션 및 서비스 설치”가 함께 보이면 OS 제어와 사용자 지정 종속성 설치를 의미하므로 IaaS/VMs를 떠올리십시오. OS 수준 설치 없이 관리형 런타임(App Service, Azure SQL, Functions)에 맞출 수 있는 경우에는 PaaS를 선택하십시오. 완전한 애플리케이션을 구매/소비하는 경우(예: Microsoft 365, Dynamics 365)에는 SaaS를 선택하십시오.
여러 Azure subscription과 virtual network 전반에서 네트워크 트래픽 필터링을 제공하는 서비스는 무엇입니까?
Azure Firewall은 여러 VNet에 대해 hub-and-spoke 설계, VNet peering 및/또는 Virtual WAN secured hub를 사용하여 중앙 집중식 네트워크 트래픽 필터링(L3-L7)을 제공하는 관리형 stateful firewall입니다. Firewall Policy를 통해 규칙을 일관되게 관리할 수 있으며, shared hub subscription에 배치하고 spoke 트래픽을 이를 통해 라우팅함으로써 여러 subscription에 걸쳐 사용할 수 있습니다.
application security group(ASG)은 그 자체로 트래픽 필터링 서비스가 아닙니다. 이는 network security group(NSG) 규칙 내에서 virtual machine NIC를 논리적으로 그룹화하여 규칙 관리를 단순화하기 위한 것입니다(예: “web tier”에서 “app tier”로). ASG는 VNet/subscription 전반의 중앙 집중식 검사를 제공하지 않으며, NSG 규칙에서 source/destination을 정의하는 데만 도움을 줍니다.
Azure DDoS Protection은 Azure의 public-facing endpoint를 분산 서비스 거부 공격(대규모 및 프로토콜 공격)으로부터 보호하는 데 도움이 됩니다. 공격 중 가용성을 향상시키고 telemetry 및 공격 분석을 제공하지만, 여러 VNet 및 subscription 전반에서의 범용 네트워크 트래픽 필터링 또는 정책 적용을 위해 설계된 것은 아닙니다.
network security group(NSG)은 VNet 내에서 subnet 또는 NIC 수준에서 inbound/outbound 트래픽에 대해 stateful L3/L4 필터링을 제공합니다. NSG는 기본적이며 널리 사용되지만, 중앙 집중식 multi-VNet, multi-subscription 트래픽 필터링 서비스는 아닙니다. 또한 Azure Firewall이 제공하는 고급 L7 기능과 중앙 검사 패턴이 부족합니다.
핵심 개념: 이 문제는 Azure 네트워크 보안 제어에 대한 이해와, 여러 virtual network(VNet) 및 여러 subscription에 걸쳐 대규모로 네트워크 트래픽을 중앙에서 필터링하고 제어할 수 있는 서비스가 무엇인지 평가합니다. 정답이 맞는 이유: Azure Firewall은 중앙 집중식 트래픽 필터링을 위해 설계된 관리형 stateful 네트워크 보안 서비스입니다. hub virtual network에 배포한 뒤 VNet peering으로 연결된 여러 spoke VNet(hub-and-spoke 토폴로지)의 트래픽을 제어하는 데 사용할 수 있으며, Azure Firewall policy 및 Azure Virtual WAN secured hub를 사용하거나(또는 firewall을 shared services subscription에 배치하여) 여러 subscription에 걸쳐 공유할 수 있습니다. 따라서 “여러 Azure subscription과 virtual network 전반에서”라는 요구사항에 가장 적합합니다. 주요 기능 / 모범 사례: Azure Firewall은 stateful L3-L7 필터링, application(FQDN) 규칙, network 규칙, DNAT, threat intelligence 기반 필터링을 제공합니다. 또한 Azure Monitor와 통합되어 로깅 및 분석을 지원합니다. Azure Well-Architected Framework(Security 및 Reliability pillar)에 부합하는 엔터프라이즈 규모 설계에서는, hub VNet에서 중앙 검사(central inspection)를 수행하고 spoke에서 firewall로 forced tunneling/UDR을 적용하며, Firewall Policy로 환경 및 subscription 전반에 걸쳐 일관된 규칙 관리를 하는 패턴이 일반적입니다. 흔한 오해: NSG와 ASG는 Azure Firewall과 자주 혼동됩니다. NSG는 단일 VNet 범위 내에서 subnet/NIC 수준으로 트래픽을 필터링합니다(다른 subscription에 생성할 수는 있지만, 중앙 집중식 multi-VNet 필터링 서비스는 아닙니다). ASG는 NSG 규칙을 위해 NIC를 그룹화하는 방법일 뿐이며, 독립적인 필터링 서비스가 아닙니다. Azure DDoS Protection은 대규모 공격 완화에 초점이 있으며, 일반적인 트래픽 필터링을 위한 서비스가 아닙니다. 시험 팁: “centralized”, “across multiple VNets”, “hub-and-spoke”, “shared service across subscriptions” 같은 표현이 보이면 Azure Firewall(또는 경우에 따라 Virtual WAN security)을 떠올리세요. “subnet/NIC rules”가 보이면 NSG를, “group VMs for NSG rules”가 보이면 ASG를, “mitigate DDoS attacks”가 보이면 Azure DDoS Protection을 떠올리세요.
HOTSPOT - 다음 각 진술에 대해, 진술이 참이면 Yes를 선택합니다. 그렇지 않으면 No를 선택합니다. 참고: 각 정답 선택은 1점입니다. 핫 영역:
Azure Firewall은 Azure에서 Internet으로 전송되는 모든 네트워크 트래픽을 암호화합니다.
Azure Firewall은 Azure에서 Internet으로 전송되는 모든 네트워크 트래픽을 자동으로 암호화하지 않습니다. Azure Firewall은 주로 트래픽을 제어하고 검사하는 데 사용되는 관리형 stateful firewall입니다(예: application 및 network rules, threat intelligence 기반 filtering, logging). 이는 트래픽이 어디로 허용되는지 강제할 수 있고 outbound connectivity 거버넌스에 도움이 될 수 있지만, 모든 outbound flow를 투명하게 암호화하지는 않습니다. Internet으로의 전송 중 암호화는 일반적으로 HTTPS/TLS, SSH 같은 protocol을 사용하거나 VPN/IPsec 또는 기타 secure tunnel을 통해 트래픽을 터널링함으로써 달성됩니다. Azure Firewall은 이러한 메커니즘과 함께 사용할 수는 있지만(예: outbound를 HTTPS만 허용하거나, 트래픽을 NVA/VPN을 통해 강제), firewall 자체가 “모든 egress traffic을 암호화”하는 서비스는 아닙니다. 따라서 정답은 아니요입니다. 예라고 답하면 트래픽 filtering/inspection을 암호학적 보호와 혼동하게 됩니다.
network security group (NSG)는 Azure에서 Internet으로 전송되는 모든 network traffic을 암호화합니다.
Network Security Group (NSG)는 traffic을 암호화하지 않습니다. NSG는 source/destination IP, port, protocol을 기반으로 한 규칙을 사용하여 Layer 3/4에서 Azure resources로의 inbound 및 outbound traffic을 허용하거나 거부하는 데 사용됩니다. 이는 본질적으로 Azure VNet 및 NIC에 대한 access control lists (ACLs)입니다. NSG는 traffic이 허용되는지 여부만 제어하므로, 허용된 packets에 대한 기밀성 또는 암호화를 제공하지 않습니다. VM이 Internet으로 HTTP traffic을 보내고 NSG가 이를 허용하더라도, application이 암호화된 protocol(예: HTTPS)을 사용하거나 tunnel이 설정되지 않는 한 traffic은 암호화되지 않은 상태로 유지됩니다. 따라서 정답은 아니요입니다. 예를 선택하면, 목적이 segmentation 및 traffic filtering이지 cryptography가 아닌 서비스에 암호화 기능이 있다고 잘못 부여하는 것입니다.
Windows Server 2016을 실행하는 Azure virtual machines는 Internet으로 전송되는 network traffic을 암호화할 수 있습니다.
Windows Server 2016을 실행하는 Azure virtual machines는 Internet으로 전송되는 network traffic을 암호화할 수 있지만, 이는 Azure가 모든 outbound traffic을 자동으로 암호화하기 때문이 아니라 OS/application 구성과 사용되는 protocol을 통해 달성됩니다. 예를 들어, Windows Server VM은 web traffic에 HTTPS (TLS)를 사용하거나, IPsec VPN tunnel을 설정하거나, (설치된 구성 요소를 통해) SSH를 사용하거나, 기타 암호화된 application protocol을 사용할 수 있습니다. 시험 관점에서 핵심은 VM이 적절히 구성되면 암호화된 traffic(전송 중 암호화, encryption in transit)을 생성할 수 있다는 점입니다. 이는 주로 traffic 제어/검사 서비스인 NSGs 또는 Azure Firewall과는 다릅니다. 따라서 해당 문장은 참입니다(예): VM은 암호화 기능이 있는 protocol과 구성을 사용하여 Internet으로의 traffic을 암호화할 수 있습니다. 다만 “항상 암호화된다”가 아니라 “할 수 있다”는 뉘앙스가 중요합니다.
참고: 이 질문은 동일한 시나리오를 제시하는 일련의 질문 중 일부입니다. 이 시리즈의 각 질문에는 명시된 목표를 충족할 수 있는 고유한 솔루션이 포함되어 있습니다. 일부 질문 세트에는 정답이 둘 이상 있을 수 있으며, 다른 세트에는 정답이 없을 수도 있습니다. 이 섹션에서 질문에 답한 후에는 해당 질문으로 돌아갈 수 없습니다. 따라서 이러한 질문은 검토 화면에 표시되지 않습니다. 귀사는 모든 데이터와 리소스를 Azure로 마이그레이션할 계획입니다. 회사의 마이그레이션 계획에는 Azure에서 Platform as a Service (PaaS) 솔루션만 사용해야 한다고 명시되어 있습니다. 회사 마이그레이션 계획을 충족하는 Azure 환경을 배포해야 합니다. 솔루션: Azure App Service 및 Azure SQL databases를 생성합니다. 이것이 목표를 충족합니까?
예. Azure App Service는 Microsoft가 기본 servers, operating systems, runtime infrastructure를 관리하고 사용자는 application code를 배포하기 때문에 PaaS 서비스입니다. Azure SQL Database도 host machines 또는 SQL Server installation을 유지 관리할 필요 없이 관리형 relational database engine을 제공하므로 PaaS 서비스입니다. 솔루션의 두 구성 요소가 모두 PaaS 서비스이므로, 제안된 환경은 PaaS 솔루션만 사용해야 한다는 회사의 요구 사항을 충족합니다.
아니오는 틀렸습니다. 제안된 솔루션에는 IaaS 구성 요소가 포함되어 있지 않기 때문입니다. 만약 솔루션이 Azure Virtual Machines 또는 Azure VMs의 SQL Server를 사용했다면, 인프라 관리가 필요하므로 PaaS 전용 요구 사항을 위반했을 것입니다. 여기서는 App Service와 Azure SQL Database가 모두 관리형 플랫폼 서비스이므로 목표가 충족됩니다.
핵심 개념: 이 문제는 Azure Platform as a Service (PaaS) 제공 사항을 식별할 수 있는지 평가합니다. 회사는 Azure에서 PaaS 솔루션만 사용해야 하므로, 제안된 서비스는 둘 다 사용자가 직접 관리하는 인프라가 아니라 관리형 플랫폼 서비스여야 합니다. 정답인 이유: Azure App Service는 기본 virtual machines 또는 operating systems를 관리하지 않고 web apps, APIs, mobile back ends를 호스팅하기 위한 PaaS 서비스입니다. Azure SQL Database 역시 Microsoft가 인프라, patching, backups, high availability의 많은 부분을 처리하는 관리형 relational database 서비스를 제공하는 PaaS 서비스입니다. 두 서비스 모두 PaaS이므로, 이 솔루션은 제시된 목표를 충족합니다. 주요 특징 / 알아둘 점: - Azure App Service는 application hosting을 위한 완전 관리형 플랫폼입니다. - Azure SQL Database는 VM에서 실행되는 SQL Server가 아니라 관리형 database platform service입니다. - PaaS는 Azure가 기본 인프라를 관리하므로 IaaS와 비교해 administrative overhead를 줄여 줍니다. - 요구 사항은 PaaS 솔루션만 사용해야 한다고 명시하므로, Azure Virtual Machines 같은 서비스는 적합하지 않습니다. 흔한 오해: 흔한 실수 중 하나는 Azure SQL Database를 Azure Virtual Machines에 설치된 SQL Server와 혼동하는 것입니다. 전자는 PaaS이고, 후자는 VM과 OS를 사용자가 관리하므로 IaaS입니다. 또 다른 오해는 Azure의 모든 hosted service가 자동으로 PaaS라고 생각하는 것입니다. 시험 문제는 관리형 플랫폼 서비스와 인프라 서비스를 구분할 수 있는지 자주 평가합니다. 시험 팁: - managed, no OS management, automatic patching, built-in scaling 같은 키워드를 찾아 PaaS를 식별하세요. - App Service, Azure SQL Database, Functions는 AZ-900에서 자주 나오는 PaaS 예시입니다. - Virtual Machines, virtual networks, storage accounts는 기본적으로 모두 PaaS가 아니므로, 문맥에서 각 서비스를 주의 깊게 읽으세요.
참고: 이 질문은 동일한 시나리오를 제시하는 일련의 질문 중 하나입니다. 이 시리즈의 각 질문에는 제시된 목표를 충족할 수도 있는 고유한 솔루션이 포함되어 있습니다. 일부 질문 세트에는 정답이 둘 이상 있을 수 있으며, 다른 세트에는 정답이 없을 수도 있습니다. 이 섹션에서 질문에 답한 후에는 해당 질문으로 돌아갈 수 없습니다. 따라서 이러한 질문은 검토 화면에 표시되지 않습니다. Azure 환경이 있습니다. Android 운영 체제를 실행하는 태블릿에서 새 Azure virtual machine을 만들어야 합니다. 솔루션: Azure Cloud Shell에서 PowerShell을 사용합니다. 이것이 목표를 충족합니까?
예. Azure Cloud Shell은 Azure에서 실행되고 web browser를 통해 접근하는 호스팅된 PowerShell 환경을 제공하므로, 로컬 operating system이 native PowerShell 설치를 지원할 필요가 없습니다. Android tablet은 Azure portal을 열고, Cloud Shell을 실행한 다음, Azure PowerShell commands를 실행하여 virtual machine을 생성할 수 있습니다. 이는 요구 사항이 tablet에서 VM을 생성하는 것이지, 디바이스에 로컬 설치된 administrative tools를 실행하는 것이 아니므로 목표를 충족합니다.
아니요는 virtual machine 생성에 로컬 설치된 Windows 기반 PowerShell 환경이 필요하다고 가정하기 때문에 틀렸습니다. 실제로 Azure Cloud Shell은 관리되는 browser session으로 PowerShell을 제공하여 이러한 의존성을 제거합니다. Cloud Shell은 Android tablets를 포함한 mobile devices에서 접근할 수 있으므로, tablet의 operating system은 장애 요소가 아닙니다. 실제로 필요한 것은 browser access, connectivity, 그리고 충분한 Azure permissions뿐입니다.
핵심 개념: Azure Cloud Shell은 Microsoft가 호스팅하는 브라우저로 접근 가능한 command-line 환경으로, Bash와 PowerShell을 모두 지원합니다. 정답인 이유: Cloud Shell은 로컬 디바이스가 아니라 Azure에서 실행되므로, Android tablet을 사용해 Azure portal 또는 지원되는 브라우저를 통해 virtual machine을 포함한 Azure 리소스를 생성하고 관리할 수 있습니다. 주요 기능: Cloud Shell은 Azure에 대한 인증된 액세스를 제공하고, Azure PowerShell modules와 Azure CLI를 포함하며, tablet에 management tools를 로컬 설치할 필요가 없습니다. 흔한 오해: 많은 학습자가 로컬 PowerShell 요구 사항과 Cloud Shell 기능을 혼동하여, mobile device는 Windows PowerShell을 기본적으로 실행하지 못하므로 사용할 수 없다고 가정합니다. 시험 팁: 문제에서 Cloud Shell이 언급되면, 사용자가 인터넷 액세스와 적절한 Azure permissions를 가지고 있는 한 이것이 브라우저 기반이며 디바이스에 독립적이라는 점에 집중하세요.
