50개 문제와 45분 시간 제한으로 실제 시험을 시뮬레이션하세요. AI 검증 답안과 상세 해설로 학습하세요.
AI 기반
모든 답안은 3개의 최고 AI 모델로 교차 검증하여 최고의 정확도를 보장합니다. 선택지별 상세 해설과 심층 문제 분석을 제공합니다.
퍼블릭 클라우드의 두 가지 특징은 무엇입니까? 각 정답은 완전한 솔루션을 제시합니다. 참고: 각 정답 선택은 1점입니다.
전용 하드웨어는 퍼블릭 클라우드의 표준 특성이 아닙니다. 퍼블릭 클라우드는 일반적으로 논리적 격리(멀티 테넌시)를 갖춘 공유 물리 인프라를 사용합니다. Azure는 규정 준수 또는 라이선스 요구를 위해 전용 옵션(예: Azure Dedicated Host, isolated SKUs)을 제공하지만, 이는 퍼블릭 클라우드를 정의하는 모델이라기보다 특수 서비스입니다.
보안되지 않은 연결은 퍼블릭 클라우드의 특성이 아닙니다. 퍼블릭 클라우드 서비스는 강력한 identity(Microsoft Entra ID), 전송/저장 시 암호화, 네트워크 제어(NSGs, firewalls), private connectivity 옵션(VPN/ExpressRoute, Private Link)을 통해 보안이 설계됩니다. 보안은 공유 책임이며 퍼블릭 클라우드의 고유한 약점이 아닙니다.
제한된 스토리지는 일반적인 퍼블릭 클라우드 특성과 반대입니다. 퍼블릭 클라우드 플랫폼은 온디맨드로 확장 가능한 스토리지(예: Azure Blob Storage, managed disks, Azure Files)를 다양한 성능 및 중복성 티어로 제공합니다. quota와 service limits가 존재하긴 하지만, 모델은 본질적으로 제한적이라기보다 탄력적이고 확장 가능합니다.
사용량 기반 과금은 퍼블릭 클라우드의 핵심 특성입니다. 측정된 소비량(CPU 시간, GB-month 스토리지, 트랜잭션, 대역폭 등)에 따라 사용한 만큼 지불합니다. Azure는 소비 기반 과금을 지원하며 커밋먼트 기반 할인(Reserved Instances, Savings Plans)도 제공하지만, 사용량은 여전히 측정되고 그에 따라 청구되므로 “measured service” 개념과 일치합니다.
셀프 서비스 관리는 퍼블릭 클라우드의 대표적 특성입니다. 고객은 제공자 개입 없이 온디맨드로 리소스를 프로비저닝, 구성, 해제할 수 있습니다. Azure에서는 portal, APIs, ARM/Bicep, Azure CLI/PowerShell, automation tools를 통해 이를 지원합니다. 이는 빠른 프로비저닝, 민첩성, Infrastructure as Code를 통한 운영 일관성을 뒷받침합니다.
핵심 개념: 이 문제는 AZ-900에서 일반적으로 강조되는 퍼블릭 클라우드의 기본 특징인 소비 기반(종량제) 과금과 온디맨드 셀프 서비스를 평가합니다. 퍼블릭 클라우드는 제3자 제공자(예: Microsoft Azure)가 인터넷을 통해 제공하는 클라우드 서비스로, 논리적 격리를 갖춘 공유 인프라를 사용합니다. 정답이 맞는 이유: D(사용량 기반 과금)는 퍼블릭 클라우드의 대표적인 특성입니다. 고객은 측정된 사용량(컴퓨팅 시간, 소비한 스토리지, 요청 수, egress 대역폭 등)에 따라 비용을 지불합니다. 이는 NIST 클라우드 모델의 “measured service”와 일치하며 Azure의 소비 모델의 핵심입니다(일부 서비스는 예약 용량/커밋먼트도 제공하지만, 여전히 사용량 측정을 기반으로 합니다). E(셀프 서비스 관리) 또한 핵심입니다. 고객은 제공자와의 사람 간 상호작용 없이 필요 시 리소스를 프로비저닝하고 관리할 수 있습니다. Azure에서는 Azure portal, ARM/Bicep templates, Azure CLI/PowerShell, APIs를 통해 이를 수행하며, 빠른 프로비저닝과 탄력성을 지원합니다. 주요 기능 / 모범 사례: 퍼블릭 클라우드는 일반적으로 빠른 프로비저닝, 확장성/탄력성, 글로벌 도달 범위, 공유 책임 모델을 제공합니다. Azure Well-Architected Framework 관점에서 사용량 기반 과금은 Cost Optimization(사용한 만큼만 지불, 적정 규모 조정, autoscale, dev/test 종료)을 지원하고, 셀프 서비스 관리는 Operational Excellence(자동화, IaC, 반복 가능한 배포, 정책 기반 거버넌스)를 지원합니다. Azure는 또한 Cost Management + Billing, budgets, tagging 같은 도구로 소비를 관리할 수 있습니다. 흔한 오해: “A. dedicated hardware”는 퍼블릭 클라우드에서 존재할 수 있지만(예: Azure Dedicated Host), 퍼블릭 클라우드의 일반적 특성은 아니며 특수 옵션입니다. “B. unsecured connections”는 퍼블릭 클라우드가 암호화, private endpoints, VPN/ExpressRoute, NSGs, firewalls, identity controls로 보안을 적용할 수 있으므로 틀립니다. “C. limited storage”는 퍼블릭 클라우드가 확장 가능하고 사실상 온디맨드 스토리지 용량으로 알려져 있으므로 틀립니다. 시험 팁: AZ-900에서는 퍼블릭 클라우드를 NIST 특성에 매핑하세요: on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service. “사용량 기반 과금”과 “셀프 서비스”가 보이면 퍼블릭 클라우드 기본 개념을 강하게 시사합니다.
이동 중에도 모든 문제를 풀고 싶으신가요?
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
이동 중에도 모든 문제를 풀고 싶으신가요?
무료 앱 받기
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
100대의 서버가 포함된 온-프레미스 네트워크가 있습니다. 사용자에게 추가 리소스를 제공하는 솔루션을 권장해야 합니다. 솔루션은 자본 지출(CapEx)과 운영 지출(OpEx) 비용을 최소화해야 합니다. 권장 사항에 무엇을 포함해야 합니까?
public cloud로의 완전한 마이그레이션은 온-프레미스 하드웨어 구매를 없애 CapEx를 줄일 수 있고, managed services를 통해 일부 OpEx를 낮출 수도 있습니다. 그러나 조직이 이미 상당한 온-프레미스 투자를 보유하고 있고 추가 용량만 필요하다면 “완전한 마이그레이션”이 항상 비용을 가장 최소화하는 권장 사항은 아닙니다. 또한 마이그레이션 프로젝트는 전환 비용, 시간, 그리고 잠재적 리팩터링을 수반합니다.
추가 data center는 CapEx와 OpEx를 모두 증가시킵니다. 토지/공간, 서버, 네트워킹, 스토리지를 구매해야 하며, 전력, 냉각, 물리 보안, 유지보수, 인력에 대한 지속 비용을 지불해야 합니다. 이는 자본 및 운영 지출을 최소화해야 한다는 요구 사항과 정면으로 충돌하며, cloud의 탄력성 이점도 제공하지 못합니다.
private cloud는 cloud와 유사한 관리 및 가상화를 제공하지만, 여전히 조직이 소유하고 운영(또는 전용 호스팅)합니다. 일반적으로 하드웨어에 대한 상당한 초기 투자와 지속적인 운영 관리가 필요하므로, 필요 시 public cloud 리소스를 사용하는 것에 비해 CapEx/OpEx를 최소화하지 못합니다. 또한 동일한 수준의 탄력성과 pay-as-you-go 경제성을 제공하지 못합니다.
hybrid cloud는 기존 온-프레미스 서버를 유지하면서 필요 시 Azure를 사용해 추가 용량을 확보할 수 있게 합니다. 이는 pay-as-you-go 확장을 지원하여 CapEx를 줄이고, 일부 운영 책임을 cloud provider에 맡겨 OpEx를 줄입니다. 온-프레미스 워크로드를 유지하면서 cloud bursting, dev/test, backup, disaster recovery에 흔히 사용하는 접근 방식입니다.
핵심 개념: 이 문제는 cloud 배포 모델과 비용 최적화를 평가합니다. 핵심 아이디어는 cloud의 탄력성(수요에 따라 필요 시 확장/축소)을 활용하여 온-프레미스 하드웨어를 추가로 구매하고 운영하지 않고도 용량을 늘리는 것입니다. 정답이 맞는 이유: hybrid cloud는 온-프레미스 인프라와 public cloud 리소스를 결합합니다. 기존에 100대의 온-프레미스 서버가 있으므로, 추가 compute/storage가 필요할 때 새 서버를 구매(자본 지출)하거나 data center를 구축/확장하는 대신 Azure로 “burst”할 수 있습니다. 이는 초기 하드웨어 구매를 피함으로써 CapEx를 최소화하고, 전력/냉각/물리 보안/하드웨어 수명주기 관리에 대한 지속 비용을 줄여 OpEx도 최소화합니다. 실무에서는 안정적으로 필요한 워크로드는 온-프레미스에 유지하고, 변동 또는 피크 수요, disaster recovery, dev/test, 또는 신규 서비스에는 Azure를 사용합니다. 주요 기능 및 모범 사례: hybrid는 일반적으로 연결(VPN Gateway 또는 ExpressRoute), ID 통합(Microsoft Entra ID와 hybrid identity), 그리고 관리/거버넌스(Azure Arc, Azure Policy)를 통해 구현됩니다. “추가 리소스”에 대한 전형적인 패턴으로는 virtual machines/scale sets를 활용한 cloud bursting, storage 추가(Azure Storage), 또는 운영 부담을 줄이기 위한 PaaS 서비스 사용이 있습니다. Azure Well-Architected Framework의 cost optimization pillar 관점에서, hybrid는 기존 투자 자산을 유지하면서 right-sizing과 pay-as-you-go 소비를 지원합니다. 흔한 오해: public cloud로의 완전한 마이그레이션도 CapEx를 줄일 수 있지만, 이미 상당한 온-프레미스 자산이 있고(또는 지연 시간, 데이터 상주, legacy apps 같은 제약이 있는 경우) 단지 추가 용량만 필요하다면 항상 최저 비용 또는 최단 경로가 아닙니다. private cloud는 “cloud처럼” 보이지만 여전히 하드웨어를 구매하고 운영해야 하므로 CapEx/OpEx가 더 높을 수 있습니다. 추가 data center는 가장 비용이 많이 드는 선택지입니다. 시험 팁: 문제에서 기존 온-프레미스 환경이 언급되고 “추가 리소스”가 필요하며 CapEx/OpEx를 최소화해야 한다면 “hybrid cloud”와 “cloud bursting”을 떠올리십시오. 반대로 “data center를 없애라” 또는 “모든 것을 옮겨라”라고 하면 public cloud 마이그레이션이 더 가능성이 높습니다.
귀사는 Microsoft에 Azure 환경에 대한 아키텍처 검토를 요청할 계획입니다. 현재 귀사는 Basic 지원 플랜을 보유하고 있습니다. 귀사를 위한 새로운 지원 플랜을 추천해야 합니다. 솔루션은 비용을 최소화해야 합니다. 어떤 지원 플랜을 추천해야 합니까?
Premier support는 architectural guidance와 광범위한 proactive services를 제공할 수 있으므로 technical requirement는 충족할 수 있습니다. 그러나 이는 폭넓고 지속적인 support management와 proactive engagement가 필요한 조직을 위한 상위 enterprise support offering입니다. 문제는 구체적으로 비용 최소화를 요구하므로, Premier는 필요 이상으로 비쌉니다. Professional Direct는 더 낮은 비용으로 필요한 architectural advisory capability를 제공합니다.
Developer support는 enterprise architectural review 요구보다는 trial, development, non-production use cases를 위한 것입니다. 지원 범위가 제한적이며, 공식적인 architectural review 요청이 암시하는 advisory architecture services를 포함하지 않습니다. 더 저렴하더라도 요구 사항을 충족하지 못합니다. 비용 최소화는 기능적 요구 사항이 충족된 이후에만 적용됩니다.
Professional Direct가 정답인 이유는 standard break-fix technical support를 넘어서는 advisory support와 architecture guidance capabilities를 포함하기 때문입니다. Microsoft의 architectural review는 design decisions를 평가하고 recommendations를 제공할 수 있는 experts에 대한 접근을 의미하며, 이는 Professional Direct의 benefits와 일치합니다. 또한 Premier보다 비용이 낮으므로, 요청된 서비스를 가능하게 하면서도 비용 최소화 요구 사항을 가장 잘 충족합니다. 나열된 옵션 중에서는 architecture-focused engagement 필요에 맞는 가장 낮은 tier입니다.
Standard support는 production workloads에 대한 technical support를 제공하며, 특정 severity에 대해 더 빠른 response와 24/7 access를 포함하지만, 주로 reactive support plan입니다. Professional Direct와 관련된 advisory 또는 architecture review services는 포함하지 않습니다. 문제는 구체적으로 Microsoft에 architectural review를 요청하는 것에 관한 것이며, 이는 standard technical support 이상의 것을 요구합니다. 따라서 Standard는 비용이 더 낮더라도 충분하지 않습니다.
핵심 개념: 이 문제는 Azure support plans에 대한 지식과, Microsoft로부터 architecture guidance 또는 architectural reviews와 같은 advisory support를 포함하는 plan이 무엇인지 묻습니다. AZ-900에서 Basic은 billing/subscription management만 포함하며, 더 높은 tier는 technical support를 추가하고, Professional Direct 수준에서는 advisory services를 제공합니다. 정답인 이유: 회사가 Microsoft가 architectural review를 수행하거나 지원하기를 원한다면, break-fix technical assistance를 넘어 advisory support를 포함하는 plan이 필요합니다. 나열된 옵션 중에서 Professional Direct는 Microsoft의 architecture support/advisory capabilities를 제공하는 가장 저렴한 plan입니다. 따라서 Premier와 비교해 비용을 최소화하면서도 요구 사항을 충족합니다. 주요 특징: Professional Direct는 business-critical support, Standard보다 더 빠른 response times, 그리고 architecture guidance 및 Microsoft experts의 지원과 같은 advisory services를 포함합니다. Standard는 주로 production workloads에 대한 reactive technical support이며, proactive architecture review 제공이 아닙니다. Premier는 더 광범위한 proactive services를 갖춘 상위 enterprise support model이지만, 여기서는 필요 이상으로 비쌉니다. 흔한 오해: 흔한 실수는 Standard가 production workloads를 지원하고 24/7 technical support를 제공하므로 충분하다고 가정하는 것입니다. 그러나 production support는 architectural review 또는 advisory engagement와 동일하지 않습니다. 또 다른 오해는 Premier가 분명히 이러한 서비스를 포함하므로 선택하는 것이지만, 문제는 명시적으로 비용 최소화를 요구합니다. 시험 팁: AZ-900에서는 reactive technical support와 proactive/advisory support를 구분하세요. Basic은 billing 전용, Developer는 non-production용, Standard는 production technical support용이며, Professional Direct는 advisory capabilities를 추가합니다. 요구 사항에 architecture reviews, advisory services 또는 proactive guidance가 언급되면, Professional Direct가 일반적으로 standard support plans 중 최소한의 적절한 선택입니다.
HOTSPOT - 다음 각 진술에 대해, 진술이 참이면 Yes를 선택합니다. 그렇지 않으면 No를 선택합니다. 참고: 각 정답 선택은 1점입니다. 핫 영역:
Azure 리소스를 모든 region에 배포했다면, 모든 region에서 availability zone을 구현할 수 있습니다.
아니요. Availability Zone은 모든 Azure region에서 사용할 수 있는 것은 아닙니다. Azure의 모든 region에 리소스를 배포하더라도, “zone-enabled”인 region에서만 Availability Zone을 사용할 수 있습니다. 또한 zone 지원은 region 내에서도 서비스별로 다를 수 있습니다(예: 어떤 region은 zonal VM을 지원하지만, 특정 PaaS 오퍼링은 아직 해당 region에서 zone-redundant가 아닐 수 있음). AZ-900에서는 zone이 region 기능이며 보편적으로 지원되지 않는다는 점이 핵심입니다. 올바른 접근 방식은 zonal resiliency를 고려해 설계하기 전에 공식 Azure “regions and availability zones” 문서(및 서비스별 문서)를 확인하여 해당 region이 zone을 지원하는지 검증하는 것입니다. 따라서 모든 region에서 availability zone을 구현할 수 있다는 진술은 거짓입니다.
Windows Server를 실행하는 virtual machine만 availability zone에서 생성할 수 있습니다.
아니요. Availability Zone은 Windows Server virtual machine으로 제한되지 않습니다. Azure는 Windows와 Linux 모두를 실행하는 zonal virtual machine 생성을 지원하며, zonal placement는 운영 체제 기능이 아니라 인프라 속성(zone 1/2/3)입니다. 실제로 region이 zonal deployment를 지원하고 VM size가 지원되는 경우, Windows Server, 다양한 Linux distribution, 그리고 많은 marketplace image를 특정 zone에 배포할 수 있습니다. 오답 선택지는 특정 복원력 기능이 OS별이라는 흔한 오해를 반영하지만, Azure에서는 zone과 같은 high availability 구성 요소가 compute 및 기타 서비스 전반에 폭넓게 적용됩니다. 시험 관점에서: OS 선택은 VM을 Availability Zone에 배포할 수 있는지 여부를 결정하지 않습니다.
Availability zones는 데이터와 애플리케이션을 여러 region에 복제하는 데 사용됩니다.
아니오. Availability Zones는 단일 region 내에서 높은 가용성을 제공하도록 설계되었으며, 해당 region 안의 여러 물리적으로 분리된 datacenter에 리소스를 분산합니다. 데이터와 애플리케이션을 여러 region에 복제하는 것은 Availability Zone 기능이 아니라 multi-region 재해 복구(DR) 전략입니다. Cross-region replication은 일반적으로 Azure Storage geo-redundant 옵션(GRS/GZRS), Azure SQL active geo-replication, Azure Site Recovery, 또는 Azure Front Door나 Traffic Manager를 사용한 multi-region 애플리케이션 라우팅과 같은 서비스 및 패턴으로 제공됩니다. Availability Zones는 datacenter/zone 장애로부터 보호하는 데 도움이 되며, multi-region replication은 region 전체 장애로부터 보호하는 데 도움이 됩니다. 따라서 해당 문장은 zones가 여러 region으로 복제한다고 주장하므로 올바르지 않습니다.
이 질문에서는 밑줄 친 텍스트가 올바른지 판단하기 위해 평가해야 합니다.
Azure Key Vault는 Azure Active Directory (Azure AD) 사용자 계정의 secrets를 저장하는 데 사용됩니다.
지침: 밑줄 친 텍스트를 검토하십시오. 해당 텍스트가 문장을 올바르게 만든다면 No change is needed를 선택하십시오. 문장이 올바르지 않다면, 문장을 올바르게 만드는 답안을 선택하십시오.
이 문장은 Azure Key Vault가 Azure AD user accounts(예: user passwords)의 secrets를 저장하는 데 사용된다는 의미이므로 올바르지 않습니다. User authentication credentials는 Azure AD/Entra ID에서 관리되며, Key Vault secrets로 저장했다가 가져오도록 의도되지 않습니다. Key Vault는 주로 애플리케이션/서비스 secrets, keys, certificates를 위한 것이지 end-user credential storage를 위한 것이 아닙니다. 텍스트를 변경하지 않으면 user account secrets에 대한 잘못된 함의를 그대로 유지합니다.
Azure AD administrative accounts라 하더라도 Key Vault는 해당 credentials(passwords/MFA methods)의 system of record가 아닙니다. Administrative accounts는 여전히 user identities이며, 인증 데이터는 Azure AD/Entra ID 내에서 관리되고 Key Vault에 retrievable secrets로 저장되지 않습니다. Admins가 Key Vault를 관리할 수는 있지만, 그렇다고 그들의 account secrets가 Key Vault에 있어야 한다는 뜻은 아닙니다. 이 옵션은 Key Vault의 목적과 user account credential storage 간의 근본적인 불일치를 해결하지 못합니다.
Azure Key Vault는 Personally Identifiable Information (PII)을 위한 범용 repository로 의도되지 않았습니다. Key Vault가 작은 secret values를 저장할 수는 있지만, PII는 일반적으로 적절한 암호화, access controls, data governance 기능을 갖춘 databases 또는 storage services에 저장되며, Key Vault는 cryptographic material과 application secrets를 관리합니다. PII를 대규모로 Key Vault에 사용하는 것은 주요 설계 목적이 아니며, “Azure AD user accounts의 secrets”라는 문맥과도 맞지 않습니다. 이 옵션은 주제를 바꾸지만 Key Vault의 핵심 사용 사례를 정확히 설명하지 못합니다.
Azure Key Vault는 API keys, connection strings, certificates와 같이 애플리케이션과 서비스가 사용하는 secrets를 안전하게 저장하고 관리하도록 설계되었습니다. Azure에서 “server applications”는 리소스에 인증하기 위해 service principal client secrets 또는 certificates 같은 credentials가 필요한 경우가 흔하며, Key Vault는 이러한 secrets를 저장하고 rotation하는 best-practice 위치입니다. 이는 Key Vault의 lifecycle management 기능(versioning, expiration, rotation) 및 Entra ID (Azure AD)를 통한 통제된 access와도 부합합니다. 따라서 문장을 “server applications”로 바꾸면 정확해집니다.
핵심 개념: 이 질문은 Azure Key Vault가 저장하도록 설계된 대상(secrets, keys, certificates)과, 일반적으로 어떤 유형의 identity 또는 데이터와 함께 사용되는지, 그리고 Azure AD user accounts가 무엇을 의미하는지에 대한 이해를 테스트합니다. 정답이 맞는 이유: Azure Key Vault는 “Azure AD user accounts의 secrets”를 저장하기보다는, 애플리케이션과 서비스에서 사용하는 secrets(예: connection strings, API keys, client secrets, certificates)를 저장하고 관리하는 데 일반적으로 사용됩니다. Azure AD user accounts는 Azure AD에서 관리되는 credentials(passwords, MFA methods 등)를 통해 인증하며, 이러한 user credentials는 애플리케이션 secrets처럼 Key Vault에 저장했다가 가져오는 방식으로 사용되지 않습니다. 반면, server-side applications는 Azure 리소스에 인증하기 위해 (service principal client secrets 또는 certificates 같은) non-human credentials가 필요한 경우가 많고, Key Vault는 이러한 application secrets를 위한 권장 secure store입니다. 주요 기능 / 구성: - Azure Key Vault의 Secrets, Keys, Certificates 객체(및 HSM-backed keys를 위한 Managed HSM) - 통합 패턴: 애플리케이션이 Key Vault REST API/SDK를 통해 런타임에 secrets를 가져옴 - Microsoft Entra ID (Azure AD)를 통한 Key Vault 인증/인가 및 RBAC 또는 Key Vault access policies를 통한 access control - 일반적인 사용 사례: service principal client secrets, TLS certificates, database connection strings, API tokens 저장 흔한 오해: - Key Vault가 Azure AD user passwords 또는 user credential material을 저장한다고 가정하는 것; user credentials는 identity provider(Entra ID/Azure AD)에서 관리되며, Key Vault에 retrievable secrets로 저장되지 않습니다. - “Azure AD secrets”(app registrations/service principals)와 “Azure AD user account secrets”를 혼동하는 것. Key Vault는 app/service credentials에는 적합하지만 end-user passwords에는 적합하지 않습니다. - Key Vault를 PII 같은 민감 데이터를 위한 범용 데이터 저장소로 생각하는 것; Key Vault는 임의의 민감 레코드가 아니라 secret/key/cert lifecycle management에 최적화되어 있습니다. 시험 팁: - Key Vault가 저장하는 것: apps 및 services를 위한 secrets/keys/certificates — user passwords는 아님. - app-to-Azure 인증의 경우, client secrets/certs를 Key Vault에 저장하고 Entra ID를 사용해 access를 인가. - PII는 암호화 및 access controls가 있는 적절한 데이터 저장소에 보관; Key Vault는 cryptographic material과 secrets 관리를 위한 것. - 문구에 주의: “user accounts” vs “applications/service principals”가 결정적인 포인트인 경우가 많습니다.
HOTSPOT - Azure virtual machines 및 Azure SQL databases에 사용되는 클라우드 배포 솔루션은 무엇입니까? 답하려면, 답안 영역에서 적절한 옵션을 선택하십시오. 참고: 각 정답 선택은 1점입니다. 핫 영역:
Azure virtual machines:
Azure virtual machines는 Infrastructure as a Service (IaaS)입니다. IaaS에서는 Azure가 물리 서버, 스토리지, 네트워킹, 하이퍼바이저를 제공하지만, 게스트 운영 체제와 그 위의 모든 것은 사용자가 관리할 책임이 있습니다. 여기에는 OS 구성, 패치 적용, antivirus/endpoint protection, 설치된 middleware, 그리고 애플리케이션이 포함됩니다. 또한 VM sizing, disks, 그리고 네트워크 설정(NSGs, routing 등)도 사용자가 제어합니다. 왜 PaaS가 아닌가? PaaS는 OS와 플랫폼 관리의 상당 부분을 추상화합니다(예: Azure App Service). 하지만 VM의 경우에는 그렇지 않으며, 여전히 OS를 관리해야 합니다. 왜 SaaS가 아닌가? SaaS는 사용자가 소비하는 완성된 애플리케이션(예: email 또는 CRM)입니다. VM은 완성된 애플리케이션이 아니라, 사용자가 배포하고 관리하는 compute building block이며, shared responsibility model에서 IaaS와 직접적으로 일치합니다.
Azure SQL databases:
Azure SQL Database는 Platform as a Service (PaaS)입니다. Microsoft가 OS, SQL engine patching, automated backups, built-in high availability(서비스 tier 및 configuration에 따라 다름)를 포함하여 기반 infrastructure와 database platform 구성 요소를 관리합니다. 사용자는 주로 database 자체를 관리합니다: schema design, data, queries, 논리적 수준에서의 performance tuning, 그리고 security settings(logins/users, firewall rules, auditing 등). 왜 IaaS가 아닌가? Azure VM에서 SQL Server를 실행한다면 OS와 SQL Server installation/patching을 사용자가 관리해야 하므로 IaaS입니다. Azure SQL Database는 이러한 책임을 제거합니다. 왜 SaaS가 아닌가? SaaS는 완전한 end-user application입니다. Azure SQL Database는 application에서 사용하는 database platform service이지, end-user application 자체가 아니므로 PaaS에 해당합니다.
참고: 이 문제는 동일한 시나리오를 제시하는 일련의 문제 중 일부입니다. 시리즈의 각 문제에는 제시된 목표를 충족할 수도 있는 고유한 솔루션이 포함되어 있습니다. 일부 문제 세트에는 둘 이상의 올바른 솔루션이 있을 수 있지만, 다른 문제 세트에는 올바른 솔루션이 없을 수도 있습니다. 이 섹션의 문제에 답한 후에는 해당 문제로 돌아갈 수 없습니다. 따라서 이러한 문제는 검토 화면에 표시되지 않습니다. Subscription1이라는 이름의 Azure subscription이 있습니다. Azure portal에 로그인하고 RG1이라는 이름의 resource group을 만듭니다. Azure documentation에서 VM1이라는 이름의 virtual machine을 만드는 다음 명령이 있습니다. az vm create --resource-group RG1 --name VM1 --image UbuntuLTS --generate-ssh-keys 명령을 사용하여 Subscription1에 VM1을 만들어야 합니다. 솔루션: Azure portal에서 Azure Cloud Shell을 시작하고 PowerShell을 선택합니다. Cloud Shell에서 명령을 실행합니다. 이것이 목표를 충족합니까?
이 솔루션은 목표를 충족합니다. Azure Cloud Shell은 Bash와 PowerShell 세션 모두에서 Azure CLI에 대한 액세스를 제공하기 때문입니다. 제시된 명령인 `az vm create --resource-group RG1 --name VM1 --image UbuntuLTS --generate-ssh-keys`는 유효한 Azure CLI 명령이며, 이를 Az PowerShell cmdlet으로 변환할 필요 없이 Cloud Shell PowerShell에서 실행할 수 있습니다. 사용자는 Azure portal에 로그인한 상태이고 Cloud Shell은 해당 인증 컨텍스트를 사용하므로, 이 명령은 세션에서 사용할 수 있는 subscription 컨텍스트에 VM1을 만들 수 있습니다. 따라서 Cloud Shell을 시작하고, PowerShell을 선택하고, 명령을 실행하는 것만으로 요구 사항을 충족하기에 충분합니다.
"아니요"라고 답하는 것은 Azure CLI 명령을 Azure Cloud Shell의 PowerShell 버전에서 실행할 수 없다고 잘못 가정한 것입니다. 실제로 Cloud Shell PowerShell에는 Az PowerShell module과 함께 Azure CLI도 포함되어 있으므로 `az` 명령도 지원됩니다. 예제에서는 Bash가 일반적으로 사용되지만, Cloud Shell에서 Azure CLI를 실행하기 위한 필수 조건은 아닙니다. 따라서 이 솔루션이 목표를 충족하지 못한다고 말하는 것은 기술적으로 부정확합니다.
핵심 개념: 이 문제는 PowerShell의 Azure Cloud Shell이 Azure subscription에서 virtual machine을 만들기 위한 Azure CLI 명령을 실행할 수 있는지 테스트합니다. Azure Cloud Shell에는 Bash와 PowerShell 환경이 모두 포함되어 있으며, Azure CLI는 어느 shell에서나 사용할 수 있습니다. 따라서 PowerShell을 선택해도 `az vm create` 명령이 작동하는 데 방해가 되지 않습니다. 흔한 오해는 Azure CLI 명령이 Bash에서만 작동하고 PowerShell에서는 대신 Az module cmdlet이 필요하다는 것이지만, Cloud Shell에서는 두 도구 세트를 모두 사용할 수 있습니다. 시험 팁: shell 선호도와 도구 가용성을 구분하세요. Cloud Shell PowerShell에서도 `az vm create`와 같은 Azure CLI 명령을 실행할 수 있습니다.
인증서를 저장하는 데 어떤 Azure 서비스를 사용해야 하나요?
Azure Security Center(현재 Microsoft Defender for Cloud)는 security posture management 및 workload protection 서비스입니다. 이 서비스는 security risks를 식별하고, recommendations를 제공하며, Azure 및 hybrid environments 전반에서 threats를 모니터링하는 데 도움을 줍니다. 하지만 certificates, secrets, 또는 private keys를 저장하는 repository 역할을 하지는 않으므로, 여기서는 정답이 아닙니다.
Azure Storage account는 blobs로 어떤 파일 형식( .pfx 또는 .cer 같은 인증서 파일 포함)이든 저장할 수 있지만, secure certificate lifecycle management를 위해 설계된 것은 아닙니다. encryption 및 access controls를 적용할 수는 있으나, 애플리케이션을 위한 통제된 retrieval 패턴, rotation/renewal 워크플로, 전용 secret auditing 같은 certificate-specific 기능이 부족합니다. 시험 관점에서 Storage는 인증서 저장을 위한 올바른 서비스가 아닙니다.
Azure Key Vault는 certificates, secrets, cryptographic keys를 저장하고 관리하기 위한 올바른 서비스입니다. secure storage, 세분화된 access control(RBAC/access policies), logs를 통한 auditing, 그리고 많은 Azure 서비스 및 managed identities와의 통합을 제공합니다. Key Vault는 인증서 import 및 관리를 지원하며, least privilege 및 centralized secret management 같은 모범 사례를 구현하는 데 도움이 됩니다.
Azure Information Protection(AIP)은 rights management 및 encryption policies를 사용하여 문서와 이메일을 분류, 라벨링, 보호하는 데 초점을 둡니다. 데이터 유출을 방지하고 정보에 대한 접근을 강제하는 데 도움을 주지만, 인증서나 private keys를 저장하는 서비스는 아닙니다. AIP는 콘텐츠 보호에 관한 것이지, 애플리케이션 및 인프라를 위한 cryptographic assets 관리가 아닙니다.
핵심 개념: 이 문제는 민감한 cryptographic material을 안전하게 저장하기 위한 Azure의 전용 서비스에 대한 지식을 평가합니다. Azure에서 certificates, secrets, 그리고 keys는 Azure Key Vault에 저장되며, 이 서비스는 이러한 자산을 보호하고 이에 대한 access를 제어하도록 설계되었습니다. 정답인 이유: Azure Key Vault는 certificates, secrets, 그리고 cryptographic keys를 저장하고 관리하도록 특별히 구축된 Azure 서비스입니다. 이 서비스는 secure storage, access control, 그리고 auditing을 제공하며, Azure applications 및 services와 통합되므로 certificates를 code나 configuration files에 포함할 필요가 없습니다. 주요 기능: Key Vault는 imported certificates 저장과 certificate objects 관리(관련 keys 및 secrets 포함)를 지원합니다. Azure RBAC 또는 vault access policies를 통한 access control, Azure Monitor를 통한 logging, 그리고 soft delete 및 purge protection과 같은 security features를 제공합니다. 시험 문제에서 certificates, passwords, 또는 keys를 안전하게 저장할 위치를 묻는 경우, 이것이 Azure의 표준 정답입니다. 일반적인 오해: Storage account는 certificate files를 저장할 수 있지만, secure certificate management를 위한 전용 Azure 서비스는 아닙니다. Microsoft Defender for Cloud는 security posture를 모니터링하고 개선하는 데 도움을 주지만, certificates를 저장하지는 않습니다. Azure Information Protection은 classification 및 rights management를 사용해 documents와 emails를 보호하며, certificate storage를 위한 서비스는 아닙니다. 시험 팁: AZ-900에서는 certificates, secrets, 그리고 encryption keys를 Azure Key Vault와 연관 지어야 합니다. 문제가 Azure에서 민감한 application secrets 또는 certificates를 안전하게 저장할 위치를 묻는다면, 예상되는 정답은 Key Vault입니다.
귀사는 Azure에서 Artificial Intelligence (AI) 솔루션을 배포할 계획입니다. 예측 분석 솔루션을 빌드, 테스트 및 배포하려면 무엇을 사용해야 합니까?
Azure Logic Apps는 커넥터와 트리거를 사용해 앱, 데이터, 서비스를 통합하는 로우코드 워크플로 자동화 서비스입니다. AI 솔루션 주변의 단계를 오케스트레이션(예: ML 엔드포인트 호출, 결과 라우팅, 알림 전송)할 수는 있지만, 예측 모델을 빌드, 학습, 테스트 및 배포하는 기능은 제공하지 않습니다. 이는 주로 프로세스 자동화 및 통합을 위한 서비스이지, 머신 러닝 개발을 위한 서비스가 아닙니다.
Azure Machine Learning Designer는 Azure Machine Learning 내의 시각적 드래그 앤 드롭 도구로, 엔드 투 엔드 머신 러닝 파이프라인을 생성합니다. 데이터 준비, 모델 학습, 성능 평가/테스트, 추론을 위한 모델 배포를 지원합니다. 이는 특히 시험 맥락에서 “Designer”가 노코드/로우코드 ML 워크플로를 의미하므로, 예측 분석 솔루션을 빌드, 테스트 및 배포해야 한다는 요구사항과 직접적으로 일치합니다.
Azure Batch는 대규모 병렬 및 고성능 컴퓨팅(HPC) 워크로드를 실행하기 위한 서비스입니다. 컴퓨팅 집약적 작업(데이터 처리 또는 모델 학습 스크립트의 일부 포함)을 실행하는 데 사용할 수는 있지만, 실험 추적, 모델 레지스트리, 평가 모듈, 실시간 엔드포인트로의 간편한 배포 같은 관리형 ML 라이프사이클 기능은 제공하지 않습니다. 이는 ML 플랫폼이 아니라 컴퓨팅 오케스트레이션입니다.
Azure Cosmos DB는 저지연 데이터 저장 및 복제를 위한 전역 분산 NoSQL 데이터베이스입니다. 애플리케이션 데이터나 ML 시스템에서 사용하는 피처를 저장할 수는 있지만, 예측 분석 모델을 빌드, 테스트 또는 배포하는 데 사용되지는 않습니다. AI 아키텍처에서 Cosmos DB는 일반적으로 데이터 계층 구성 요소인 반면, Azure Machine Learning은 모델 개발 및 배포 계층입니다.
핵심 개념: 이 문제는 예측 분석(머신 러닝) 솔루션을 빌드, 테스트 및 배포하는 데 사용되는 Azure 서비스를 식별하는지를 평가합니다. Azure에서 엔드 투 엔드 머신 러닝 라이프사이클(데이터 준비, 학습, 평가, 배포)을 위한 주요 관리형 서비스는 Azure Machine Learning이며, 그 노코드/로우코드 인터페이스가 Azure Machine Learning Designer입니다. 정답이 맞는 이유: Azure Machine Learning Designer는 예측 분석을 위한 머신 러닝 파이프라인을 생성할 수 있는 시각적 드래그 앤 드롭 환경을 제공합니다. 모델(예: 분류/회귀)을 빌드하고, 기본 제공 메트릭으로 테스트/평가하며, 실시간 엔드포인트(온라인 추론) 또는 배치 추론 파이프라인으로 배포하여 운영화할 수 있습니다. 이는 “예측 분석 솔루션을 빌드, 테스트 및 배포”라는 전형적인 ML 워크플로와 정확히 일치합니다. 주요 기능 및 모범 사례: Designer에는 데이터 수집, 피처 엔지니어링, 알고리즘 선택, 학습, 교차 검증, 스코어링을 위한 사전 구축 모듈이 포함됩니다. Azure Machine Learning workspace와 통합되어 실험 추적, 모델 레지스트리, MLOps 기능(대개 GitHub/Azure DevOps를 통해)을 제공합니다. 배포 측면에서 Azure ML은 관리형 온라인 엔드포인트를 호스팅할 수 있으며 확장, 인증, 모니터링을 지원하는데, 이는 신뢰성과 보안(Azure Well-Architected Framework: Reliability, Security, Operational Excellence)에 중요합니다. 또한 workspace 기반 액세스 제어(RBAC)와 Azure Monitor/Log Analytics 통합을 통해 책임 있는 AI 도구 및 거버넌스 패턴도 지원합니다. 흔한 오해: 일부 선택지는 “자동화” 또는 “컴퓨팅” 서비스로 AI 솔루션에서 간접적으로 사용할 수는 있지만, ML 모델 개발 및 배포를 위해 특별히 설계된 것은 아닙니다. 예를 들어 Azure Batch는 대규모 작업을 실행할 수 있지만 ML 파이프라인 설계, 모델 관리, 엔드포인트 배포를 제공하지 않습니다. Logic Apps는 워크플로를 오케스트레이션하는 서비스이지 ML 학습이 아닙니다. Cosmos DB는 데이터를 저장하는 서비스이지 모델을 다루는 서비스가 아닙니다. 시험 팁: AZ-900에서는 키워드를 서비스에 매핑하세요. “predictive analytics”, “train model”, “deploy model”, “ML lifecycle” 같은 표현은 일반적으로 Azure Machine Learning(Designer/Studio)을 가리킵니다. 질문이 노코드 시각적 빌드를 강조하면 “Designer”가 가장 적합합니다. 커스텀 코드와 노트북을 강조한다면 “Azure Machine Learning”을 더 일반적으로 언급할 수 있지만, 여기서는 Designer가 정답입니다.
여러 대의 Azure virtual machines를 배포할 계획입니다. Internet에 있는 디바이스가 virtual machines에 액세스하는 데 사용할 수 있는 ports를 제어해야 합니다. 무엇을 사용해야 합니까?
a network security group (NSG)가 정답인 이유는 Azure 리소스로 들어오고 나가는 네트워크 트래픽을 필터링하기 때문입니다. inbound rules를 만들어 특정 ports(예: 80/443)를 특정 sources(예: Internet 또는 신뢰할 수 있는 IP range)에서만 허용하고, 나머지는 모두 거부할 수 있습니다. NSG는 subnet 또는 NIC 수준에 적용할 수 있으며, rule priorities와 default deny 동작(Internet에서의 inbound 트래픽에 대해)을 갖는 stateful 방식입니다.
an Azure AD role은 Azure role-based access control (RBAC)에 사용되며, identity가 Azure 리소스(관리 plane)에서 수행할 수 있는 작업(예: VM 시작/중지, 설정 수정)을 제어합니다. 이는 네트워크 연결성이나 Internet에 열려 있는 TCP/UDP ports를 제어하지 않습니다. Port 제어는 NSGs, firewalls 또는 유사한 네트워크 보안 서비스가 담당하는 네트워킹 기능입니다.
an Azure AD group은 RBAC를 통해 permissions를 할당하거나 애플리케이션 및 리소스에 대한 액세스를 관리하는 데 사용되는 users/devices의 컬렉션입니다. groups는 권한 부여(누가 무엇을 관리하거나 액세스할 수 있는지)를 단순화할 수 있지만, VM에 대한 ports를 열거나 닫는 것과 같은 네트워크 계층 rules를 강제하지는 않습니다. VM ports에 대한 네트워크 액세스 제어는 NSGs(및 선택적으로 Azure Firewall/WAF)로 구현합니다.
Azure Key Vault는 secrets, encryption keys, certificates를 안전하게 저장하고 관리하도록 설계되었으며, TLS certificate 관리 및 애플리케이션 secret 저장과 같은 시나리오를 지원합니다. Key Vault 자체는 access policies/RBAC 및 vault에 대한 network controls로 보호할 수 있지만, virtual machines로의 inbound/outbound ports를 제어하지는 않습니다. Internet에 대한 VM port 노출은 NSGs 및 관련 네트워크 보안 제어로 관리합니다.
핵심 개념: 이 문제는 virtual machines에 대한 Azure 네트워크 트래픽 필터링을 테스트합니다. Azure에서 VMs에 도달할 수 있는 inbound(및 outbound) ports를 허용할지 여부를 제어하는 기본 수단은 Network Security Groups (NSGs)이며, NSG는 네트워크 계층에서 stateful packet filter로 동작합니다. 정답이 맞는 이유: Internet에 있는 디바이스가 Azure virtual machines에 액세스할 때 사용할 수 있는 ports를 제어하려면, NSG를 사용하여 inbound security rules를 정의합니다(예: Internet에서 TCP 443 허용, Internet에서 TCP 3389 거부, 특정 IP range에서만 SSH 허용). NSG는 subnet에 연결하여 해당 subnet의 모든 리소스에 영향을 주도록 할 수도 있고, 더 세밀한 제어를 위해 VM의 network interface (NIC)에 직접 연결할 수도 있습니다. 이는 Azure Well-Architected Framework의 Security pillar와도 일치하며, least privilege 네트워크 액세스를 강제하고 필요한 ports와 sources만 허용하여 노출을 줄입니다. 주요 기능 및 모범 사례: NSG에는 우선순위가 있는 rules가 포함되며(숫자가 낮을수록 우선순위가 높음) default rules(예: VNet 트래픽 허용, Internet에서의 inbound 거부)가 포함됩니다. NSG는 stateful이므로 return traffic은 자동으로 허용됩니다. source/destination IP, port, protocol로 제한할 수 있고, service tags(예: Internet, VirtualNetwork) 및 application security groups (ASGs)를 사용하여 대규모 환경에서 rule 관리를 단순화할 수 있습니다. 실제 배포에서는 고급 검사 기능을 위해 NSG를 Azure Firewall 또는 WAF와 함께 사용하는 경우가 많지만, VM port 액세스를 위한 기본 제어는 NSG입니다. 흔한 오해: Azure AD roles 및 groups는 Azure 리소스에 대한 identity 및 permissions(관리 plane)을 제어하며, 네트워크 ports(데이터 plane)를 제어하지 않습니다. Azure Key Vault는 secrets/keys/certificates를 보호하는 서비스이며, VMs로의 네트워크 트래픽을 필터링하지 않습니다. 시험 팁: 문제에서 “control ports”, “allow/deny inbound/outbound traffic”, “VM access”, “subnet/NIC rules”가 언급되면 NSG를 떠올리세요. “누가 리소스를 관리할 수 있는가”가 언급되면 Azure RBAC/Azure AD를 떠올리세요. “secrets/certificates 저장”이 언급되면 Key Vault를 떠올리세요.
