모든 답안은 3개의 최고 AI 모델로 교차 검증하여 최고의 정확도를 보장합니다. 선택지별 상세 해설과 심층 문제 분석을 제공합니다.
GPT Pro
Claude Opus
Gemini Pro
선택지별 상세 해설
심층 문제 분석
3개 모델 합의 정확도
연습 문제
1
문제 1
HOTSPOT -
다음 각 진술에 대해, 진술이 참이면 Yes를 선택합니다. 그렇지 않으면 No를 선택합니다.
참고: 각 정답 선택은 1점입니다.
핫 영역:
파트 1:
Azure subscription에서 추가 resource group을 생성하면 추가 비용이 발생합니다.
정답: 아니요 (B).
resource group은 lifecycle management, RBAC, policy assignment, cost management reporting을 위해 Azure resource를 구성하는 데 사용되는 논리적 컨테이너입니다. 추가 resource group을 생성하는 것만으로는 과금되는 resource가 배포되거나 계량되는 용량이 소비되지 않습니다. 따라서 Azure는 resource group을 더 많이 보유하는 것만으로는 요금을 부과하지 않습니다.
비용은 resource group 내부에 resource(예: virtual machine, managed disk, storage account, VPN gateway, database)를 생성하거나 사용하거나, 과금되는 활동(예: outbound data transfer, transaction, log ingestion)을 발생시킬 때 발생합니다. resource group은 Azure Resource Manager의 governance/management 기능의 일부이며, 독립적인 과금 항목으로 가격이 책정되지 않습니다.
“예”가 틀린 이유: 조직/관리용 구성 요소를 과금되는 서비스와 혼동했기 때문입니다. 해당 group에 배치된 resource와 관련된 비용은 발생할 수 있지만, group 자체를 생성하는 행위만으로는 추가 요금이 발생하지 않습니다.
파트 2:
온-프레미스 네트워크에서 VPN을 통해 Azure로 수 기가비트의 데이터를 복사하면 추가 데이터 전송 비용이 발생합니다.
정답: 아니요 (B).
온-프레미스 네트워크에서 Azure로 데이터를 복사하는 것은 Azure로의 인바운드 데이터 전송(ingress)입니다. Azure의 일반적인 대역폭 요금 모델에서 인바운드 데이터 전송은 보통 무료입니다. 따라서 VPN을 통해 수 기가비트의 데이터를 Azure로 전송(복사)하더라도, 전송 자체에 대해 Azure에서 추가 데이터 전송(대역폭) 요금이 일반적으로 부과되지는 않습니다.
시험 대비를 위한 중요한 뉘앙스: ingress 대역폭은 일반적으로 무료이지만, 청구되는 연결 구성 요소(예: Azure VPN Gateway는 시간당 과금되며 다른 요금이 있을 수 있음)를 사용한다면 전체 솔루션에는 비용이 발생할 수 있습니다. 그러나 이 문제는 Azure로 데이터를 복사함으로써 발생하는 “추가 데이터 전송 비용”을 묻고 있으므로, Gateway 실행 비용이 아니라 대역폭의 방향성에 초점이 맞춰져 있습니다.
“예”가 틀린 이유: 모든 네트워크 전송이 과금된다고 가정하기 때문입니다. AZ-900에서는 흔한 규칙을 기억하세요: Azure로의 인바운드는 일반적으로 무료이고, Azure에서 나가는 아웃바운드는 일반적으로 과금됩니다.
파트 3:
VPN을 통해 Azure에서 온-프레미스 네트워크로 수 GB의 데이터를 복사하면 추가 데이터 전송 비용이 발생합니다.
정답: 예 (A).
Azure에서 온-프레미스 네트워크로 데이터를 복사하는 것은 Azure에서 나가는(outbound) 데이터 전송(즉, egress)입니다. Azure는 일반적으로 outbound 대역폭에 대해 요금을 부과하며, 이러한 요금은 전송되는 데이터 양이 증가할수록 커집니다. 따라서 VPN을 통해 Azure에서 온-프레미스로 수 GB의 데이터를 다시 복사하는 경우 일반적으로 추가 데이터 전송 비용이 발생합니다.
이는 AZ-900 시험에서 자주 다루는 개념입니다. 데이터 egress는 전형적인 비용 요인이며, 아키텍트는 egress를 염두에 두고 설계해야 합니다(예: 워크로드와 종속 서비스를 동일한 region에 유지, 경계 간 전송 최소화, 적절한 경우 caching/CDN 패턴 사용). 이는 Azure Well-Architected Framework의 Cost Optimization pillar와도 일치합니다.
“아니요”가 틀린 이유: outbound 트래픽에 inbound는 무료라는 규칙을 잘못 적용했기 때문입니다. 일부 시나리오에서는 특별한 가격 정책(또는 특정 서비스에서의 무료 허용량)이 있을 수 있지만, 여기서 시험에서 기본적으로 확인하는 원칙은 Azure에서 나가는(outbound) 데이터 전송은 과금된다는 것입니다.
이동 중에도 모든 문제를 풀고 싶으신가요?
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
Cloud Pass를 다운로드하고 모든 Microsoft AZ-900 학습 문제를 무료로 이용하세요.
이동 중에도 모든 문제를 풀고 싶으신가요?
무료 앱 받기
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
2
문제 2
Azure Cost Management를 사용하려면 무엇이 필요합니까?
Dev/Test subscription은 개발 및 테스트 워크로드의 비용을 줄이기 위한 특정 제안(종종 Visual Studio subscriptions을 통해 제공)입니다. Azure Cost Management를 사용하기 위한 전제 조건이 아닙니다. Cost Management는 Dev/Test를 포함한 다양한 subscription 유형의 비용을 분석할 수 있지만, Dev/Test가 있어야 서비스에 접근할 수 있는 것은 아닙니다.
Software Assurance는 Microsoft volume licensing과 연관된 라이선스 혜택(예: Windows Server/SQL Server 혜택, Azure Hybrid Benefit 자격)입니다. 이는 Azure Cost Management에 대한 접근 권한을 부여하지 않습니다. Cost Management는 Software Assurance entitlement가 아니라 Azure billing 및 scopes(billing account/subscription)에 연결됩니다.
Enterprise Agreement (EA)는 대규모 조직을 위한 구매 계약이며, Azure Cost Management를 사용하기 위해 필요하지 않습니다. EA 고객이 대규모로 Cost Management를 사용하는 경우가 흔하고(종종 고급 chargeback/showback 요구), 비EA 고객도 해당 도구를 사용할 수 있습니다. EA는 구매 모델이지 기능적 전제 조건이 아닙니다.
pay-as-you-go subscription은 청구 가능한 사용량과 billing 관계를 갖춘 Azure subscription을 의미하므로, 보기 중 가장 명확한 요구 사항입니다. Azure Cost Management는 billing 및 usage data에 의존하며, pay-as-you-go subscription이 그 기준을 제공합니다. 다른 subscription/billing 유형도 많이 동작하지만, 여기서는 pay-as-you-go가 최선의 정답입니다.
문제 분석
핵심 개념:
Azure Cost Management(종종 Cost Management + Billing로도 불림)는 클라우드 지출을 모니터링, 할당, 최적화하는 데 사용되는 Azure 거버넌스 및 재무 관리 기능입니다. 비용 분석, 예산, 경고, 비용 할당(tags/management groups/subscriptions), 그리고 비용 효율을 개선하기 위한 권장 사항을 지원하며, Azure Well-Architected Framework의 Cost Optimization 축과 강하게 연관됩니다.
정답인 이유:
AZ-900 fundamentals 맥락에서 Azure Cost Management를 사용하려면 청구 가능한 사용량을 생성하고 Cost Management에서 지원되는 Azure subscription이 필요합니다. pay-as-you-go subscription은 청구를 활성화하므로 비용 추적 및 분석이 가능해지는, 기준이 되는 가장 일반적으로 언급되는 subscription 유형입니다. Cost Management는 Software Assurance나 Enterprise Agreement 같은 특별한 라이선싱 프로그램에 제한되지 않으며, Azure billing accounts 및 subscriptions 전반에서 폭넓게 사용할 수 있습니다. 시험 관점에서 “pay-as-you-go subscription”이 보기 중 가장 보편적으로 올바른 요구 사항입니다.
주요 기능 / 할 수 있는 일:
Cost Management로 다음을 수행할 수 있습니다: scope별 비용 보기(management group, subscription, resource group), tags로 필터/그룹화, 예산 및 경고 생성, 비용 데이터 내보내기, 지출 절감을 위한 권장 사항 활용(예: right-sizing, 해당되는 경우 reserved instances/savings plans). 접근은 scope에 따라 Cost Management Reader/Contributor 또는 Billing Reader 같은 Azure RBAC roles로 제어됩니다.
흔한 오해:
학습자들은 Cost Management가 과거에 EA 통합이 강했기 때문에 Enterprise Agreement (EA)가 필요하다고 생각하는 경우가 많습니다. 또 다른 오해는 Software Assurance(라이선스 혜택)를 비용 도구 접근과 혼동하는 것입니다. Dev/Test subscriptions은 개발 워크로드를 위한 가격 제안일 뿐, 비용 분석의 전제 조건이 아닙니다.
시험 팁:
AZ-900에서는 다음을 기억하세요: Cost Management는 Azure subscriptions 및 billing과 함께 제공되는 거버넌스 도구입니다. “required”를 묻는다면, 표준 Azure subscription과 billing이 있음을 의미하는 보기(pay-as-you-go)를 고르세요. 또한 권한에 대한 문구도 주의하세요—때로는 실제 요구 사항이 적절한 RBAC/billing access일 수 있지만, 이 문제에서는 해당 보기가 제공되지 않습니다.
3
문제 3
여러 서버를 포함하는 온-프레미스 네트워크가 있습니다.
모든 서버를 Azure로 마이그레이션할 계획입니다.
단일 Azure 데이터 센터가 장기간 오프라인이 되더라도 일부 서버를 사용할 수 있도록 보장하는 솔루션을 권장해야 합니다.
권장 사항에 무엇을 포함해야 합니까?
Fault tolerance는 장애(서버, 랙 또는 데이터 센터)가 발생해도 시스템이 계속 실행될 수 있는 능력입니다. 장기간의 데이터 센터 장애에 대비하려면 Availability Zones(리전 내의 분리된 데이터 센터) 및/또는 cross-region disaster recovery를 사용해 redundancy와 failover를 설계합니다. 이는 한 데이터 센터가 다운되더라도 “일부 서버를 사용할 수 있어야 한다”는 요구 사항과 직접적으로 일치합니다.
Elasticity는 수요에 맞춰 리소스를 자동으로 추가하거나 제거하는 것을 의미합니다(예: 피크 사용량 동안 autoscaling으로 확장하고 수요가 감소하면 축소). Elasticity는 가변 부하에서 비용 효율성과 성능을 개선하지만, fault-tolerant한 multi-zone 또는 multi-region 설계와 결합되지 않는 한 데이터 센터 장애로부터 본질적으로 보호해 주지는 않습니다.
Scalability는 수직적(더 큰 VM) 또는 수평적(더 많은 인스턴스)으로 용량을 늘려 성장을 처리하는 능력입니다. Elasticity와 마찬가지로 scalability는 용량과 성능에 초점을 맞추며 복원력과는 다릅니다. 모든 인스턴스가 단일 데이터 센터에 있고 그 데이터 센터를 사용할 수 없게 되면, 확장 가능한 시스템이라도 중단될 수 있습니다.
Low latency는 네트워크 지연을 최소화하여 사용자가 더 빠른 응답을 받도록 하는 것을 의미하며, 보통 더 가까운 리전을 선택하거나 CDN을 사용하거나 라우팅을 최적화하여 달성합니다. Latency는 성능 특성이지 가용성 전략이 아닙니다. 데이터 센터 또는 zone 전반의 redundancy가 없다면, low-latency 배포도 다운타임을 겪을 수 있습니다.
문제 분석
핵심 개념:
이 문제는 클라우드의 복원력(resiliency) 개념, 특히 fault tolerance(그리고 밀접하게 관련된 high availability)를 평가합니다. Fault tolerance는 구성 요소에 장애가 발생하더라도 시스템이 계속 동작할 수 있는 능력입니다. Azure 관점에서 “구성 요소”는 서버, 랙 또는 전체 데이터 센터(availability zone)일 수 있습니다.
정답이 맞는 이유:
단일 Azure 데이터 센터가 장기간 오프라인이 되면, 다른 격리된 위치에서 워크로드가 계속 실행되어야 합니다. 이 요구 사항은 한 데이터 센터의 장애가 서비스 중단으로 이어지지 않도록 설계하는 fault tolerance에 정확히 해당합니다. 실제로는 fault domains 전반에 걸쳐 배포하고, 특히 데이터 센터 수준 장애에 대비해 Availability Zones(Zone-redundant 아키텍처) 또는 paired regions(재해 복구)를 사용해 달성합니다. 문제는 개념 수준으로 표현되어 있으며, 보기 중 올바른 용어는 “fault tolerance”입니다.
주요 기능/구성(권장 사항에 포함할 내용):
- Availability Zones를 사용한 zonal redundancy: VM Scale Sets를 사용해 zone-redundant 구성으로 VM을 배치하거나, load balancers와 함께 Availability Zones를 사용합니다.
- 가능한 경우 zone-redundant services 사용(예: zone-redundant storage, 지원되는 tiers/regions에서 Azure SQL zone redundancy).
- 장기 장애 또는 지역 재해에 대비한 region-to-region DR 고려: Azure Site Recovery, database geo-replication, 그리고 Azure Front Door 또는 Traffic Manager를 통한 트래픽 라우팅.
이는 Azure Well-Architected Framework의 Reliability pillar(신뢰성 기둥)와 일치하며, redundancy, failover, recovery를 위한 설계를 의미합니다.
흔한 오해:
Elasticity와 scalability는 변화하는 수요(성능/용량)를 처리하는 것과 관련이 있으며, 데이터 센터 장애를 견디는 것과는 다릅니다. Low latency는 응답 시간과 근접성에 관한 것이지, 복원력과는 관련이 없습니다.
시험 팁:
“데이터 센터가 오프라인”을 보면 Availability Zones(데이터 센터 수준 격리)를 떠올리세요. “리전이 오프라인”을 보면 paired regions와 disaster recovery를 떠올리세요. 문제가 포괄적인 개념을 묻는다면, 성능 관련 용어가 아니라 fault tolerance/high availability를 선택하세요.
4
문제 4
HOTSPOT -
월간 가동 시간 백분율을 어떻게 계산해야 합니까? 답하려면 답안 영역에서 적절한 옵션을 선택하십시오.
참고: 각 정답 선택은 1점입니다.
핫 영역:
파트 1:
첫 번째 선택
월간 가동률(업타임) 백분율 공식의 분자는 해당 월 동안 서비스가 실제로 가용했던 시간을 나타내야 합니다. 이는 가능한 총 시간에서 가용하지 않았던 시간을 뺀 값으로 계산됩니다.
따라서 올바른 첫 번째 선택은 (최대 가용 분 – 분 단위 다운타임)입니다. 이는 해당 월의 “가용 분”을 산출합니다.
다른 선택지가 틀린 이유:
- 분 단위 다운타임(A)만으로는 업타임이 아니라 그 반대 지표입니다. 다운타임을 분자로 사용하면 다운타임이 증가할수록 백분율이 잘못 증가하게 됩니다.
- 최대 가용 분(B)만 사용하면 다운타임을 완전히 무시하므로 장애가 있어도 항상 100% 업타임을 의미하게 됩니다.
SLA 관점에서는 항상 총 측정 구간에서 다운타임을 빼서 실제 업타임을 구한 다음, 이를 총 측정 구간으로 나눕니다.
파트 2:
두 번째 선택
한 달의 최대 가용 분을 계산하려면 일반적으로 일 → 시간 → 분 순으로 구성합니다. 시간에서 분으로 변환할 때의 핵심 변환 계수는 1시간당 60분입니다.
선택지(60, 1,440, 최대 가용 분) 중에서 올바른 두 번째 선택은 1,440이며, 이는 하루의 분 수(24 × 60 = 1,440)를 나타내기 때문입니다. 많은 가동률 계산에서 월간 분은 (해당 월의 일 수 × 1,440)로 계산하는 것을 볼 수 있습니다.
다른 선택지가 틀린 이유:
- 60(A)은 시간당 분 수이지만, 일반적인 월간 계산의 지름길은 하루당 분 수(1,440)입니다. 60을 사용하면 추가 단계(하루당 시간 수)가 필요합니다.
- 최대 가용 분(C)은 최종 계산된 값이며, 이를 계산하는 데 사용하는 변환 계수가 아닙니다.
파트 3:
세 번째 선택
가동률(업타임) 퍼센트는 백분율로 표현되므로, 가동률 비율(가용 분 ÷ 최대 가용 분)을 계산한 후 100을 곱합니다.
따라서 올바른 세 번째 선택은 100입니다.
다른 선택지가 틀린 이유:
- 99.99(B)는 특정 SLA 목표(흔히 “four nines”라고 부름)이며, 비율을 백분율로 변환하기 위해 곱하는 값이 아닙니다. 계산된 결과를 99.99%와 비교할 수는 있지만, 99.99를 곱하지는 않습니다.
- 1.440(C)은 1,440(하루당 분)이라는 값을 잘못 표기한 것으로 보입니다. 이 값은 월의 총 분을 계산하기 위해 앞 단계에서 사용되며, 최종 백분율 변환을 위한 곱셈 값이 아닙니다.
따라서 최종 구조는 다음과 같습니다: ((Maximum Available Minutes – Downtime in Minutes) / Maximum Available Minutes) × 100.
5
문제 5
Azure 환경에서 여러 개의 managed Microsoft SQL Server 인스턴스를 생성하려고 시도했지만 Azure subscription limits를 늘려야 한다는 메시지를 받습니다.
limits를 늘리려면 무엇을 해야 합니까?
service health alert를 생성하는 것은 Azure 서비스 incident, planned maintenance, 또는 health advisories에 대한 알림을 받기 위한 것입니다. subscription quotas를 변경하거나 추가 SQL Managed Instances 생성을 가능하게 하지는 않습니다. alerts는 monitoring/governance 기능이지, Microsoft에 용량 또는 quota 변경을 요청하는 메커니즘이 아닙니다.
support plan을 업그레이드하면 더 빠른 응답 시간, 추가 지원 채널, 또는 아키텍처 가이던스를 제공받을 수 있지만, subscription limits를 자동으로 늘리지는 않습니다. quota 증가는 여전히 quota request 제출이 필요합니다. 더 높은 support plan이 처리 속도를 높이는 데 도움이 될 수는 있지만, limit를 올리는 직접적인 조치는 아닙니다.
Azure Policy는 조직 표준을 강제하고 compliance를 평가하는 데 사용됩니다(예: region 제한, tags 요구, 허용되는 SKU 제한). Microsoft가 강제하는 서비스 quotas를 무시할 수는 없습니다. policy가 배포를 허용하더라도 subscription quota에 도달하면 플랫폼이 여전히 이를 차단합니다.
새 support request를 생성하는 것이 Azure subscription quotas/limits를 늘리는 올바른 방법입니다. Azure portal에서 “Service and subscription limits (quotas)” 아래로 quota increase request를 제출합니다. Microsoft가 관련 subscription, region, resource type에 대한 quota를 검토하고 조정하여 추가 SQL Managed Instances를 배포할 수 있게 합니다.
문제 분석
핵심 개념:
이 문제는 Azure subscription 및 서비스 limits(quotas라고도 함)를 테스트합니다. Azure SQL Managed Instance를 포함한 많은 Azure 리소스는 subscription별, region별 quota(예: vCore limits, 인스턴스 수, 또는 기타 용량 제약)의 적용을 받습니다. quota에 도달하면 quota가 증가될 때까지 Azure는 추가 배포를 차단합니다.
정답이 맞는 이유:
Azure subscription limits/quotas를 늘리려면 일반적으로 Azure Support를 통해 quota increase request를 제출해야 하며, 이를 위해 새 support request를 생성합니다(대개 “Service and subscription limits (quotas)”로 분류). 이렇게 하면 Microsoft로 요청이 전달되어 해당 subscription/region에 대한 백엔드 quota를 조정합니다. SQL Managed Instance 같은 managed 서비스의 quota 증가는 policy나 모니터링으로 자체 처리할 수 있는 것이 아니라 support 워크플로가 필요합니다.
주요 기능 및 모범 사례:
- Quotas는 범위가 정해져 있으며(subscription, region, resource type), role-based access (RBAC) permissions와는 별개입니다.
- 요청은 Azure portal에서 수행합니다: Help + support -> Create a support request -> Quota.
- 용량을 미리 계획하세요(Azure Well-Architected Framework: Cost Optimization 및 Reliability). quota 제약은 피크 수요 시 scaling이 차단될 수 있어 reliability risk가 될 수 있습니다.
- regional 전략을 고려하세요. 특정 region이 제약을 받는 경우 다른 region에 배포하는 것이 우회책이 될 수 있지만, latency, data residency, DR 설계에 영향을 줍니다.
흔한 오해:
- “limits”를 “policies”와 혼동하는 경우가 있습니다. Azure Policy는 compliance(허용되는 SKU/위치/tags)를 관리하며, Microsoft가 강제하는 서비스 quotas가 아닙니다.
- support plan을 업그레이드하면 응답 시간이나 지원 접근성이 개선될 수 있지만, quotas가 자동으로 증가하지는 않습니다.
- Service Health alerts는 장애/권고 사항을 알려주기 위한 것이지 quota 소진을 해결하는 것이 아닙니다.
시험 팁:
AZ-900에서 “increase subscription limits/quotas”가 보이면 기대되는 조치는 “support request를 생성”하는 것입니다. 기억하세요: monitoring/alerts는 알려주고, policy는 제한하며, quota 증가는 Azure Support requests를 통해 처리됩니다.
6
문제 6
참고: 이 문제는 동일한 시나리오를 제시하는 일련의 문제 중 일부입니다. 이 시리즈의 각 문제에는 명시된 목표를 충족할 수 있는 고유한 솔루션이 포함되어 있습니다. 일부 문제 세트에는 정답이 두 개 이상 있을 수 있으며, 다른 문제 세트에는 정답이 없을 수도 있습니다.
이 섹션의 문제에 답한 후에는 해당 문제로 돌아갈 수 없습니다. 따라서 이러한 문제는 검토 화면에 표시되지 않습니다.
여러 대의 Azure virtual machines를 배포할 계획입니다.
단일 data center에 장애가 발생하더라도 virtual machines에서 실행 중인 서비스가 사용 가능하도록 보장해야 합니다.
솔루션: virtual machines를 두 개 이상의 availability zones에 배포합니다.
이것이 목표를 충족합니까?
예. Standard support에는 Microsoft support engineers에 대한 접근이 포함된 기술 지원이 있으며, 전화 및 이메일과 같은 연락 옵션(심각도 기반 응답 목표 포함)을 제공합니다. 정책이 전화 또는 이메일로 support engineers에게 연락할 수 있는 옵션을 요구하므로, Standard는 요구 사항을 충족하며 프로덕션 운영 요구에 대한 기준 플랜으로 흔히 간주됩니다.
아니요가 정답이 되려면 솔루션이 data center 수준의 장애를 해결하지 못해야 합니다. 그러나 Availability Zones는 단일 data center(존) 장애로부터 보호하도록 특별히 설계되었습니다. 주요 주의점은 애플리케이션이 여러 존의 인스턴스를 사용하도록 구성되어야 한다는 것(예: load balancing 및 복원력 있는 종속성)인데, 제안된 배포 방식은 명시된 목표를 충족합니다.
문제 분석
핵심 개념:
이 문제는 Azure Availability Zones와 이것이 virtual machines의 복원력을 어떻게 향상시키는지에 대한 이해를 평가합니다. Availability Zones는 Azure region 내에서 물리적으로 분리된 위치이며, 각각 독립적인 전원, 냉각 및 네트워킹을 갖추고 있습니다. 여러 zone에 걸쳐 VM을 배포하면 단일 datacenter 장애로부터 워크로드를 보호하는 데 도움이 됩니다.
정답인 이유:
목표는 단일 datacenter에 장애가 발생하더라도 서비스를 계속 사용할 수 있도록 유지하는 것입니다. virtual machines를 두 개 이상의 Availability Zones에 배치하면 각 zone이 동일한 region 내에서 서로 격리되어 있으므로 이 요구 사항을 직접적으로 충족합니다. 하나의 zone을 사용할 수 없게 되더라도 다른 zone의 VM은 계속 실행될 수 있습니다.
주요 기능 / 알아둘 사항:
- Availability Zones는 단일 Azure region 내에서 고가용성을 제공합니다.
- 각 zone은 독립적인 인프라를 갖춘 별도의 물리적 위치입니다.
- zonal 또는 zone-redundant 아키텍처는 datacenter 수준의 장애를 견디기 위해 사용됩니다.
- 전체 서비스 가용성을 위해서는 일반적으로 워크로드에 load balancing과 application 수준의 복원력도 필요합니다.
흔한 오해:
흔한 오해 중 하나는 Availability Set이 datacenter 장애로부터 보호한다는 것입니다. Availability Set은 datacenter 내의 host 및 rack 수준 장애로부터는 보호하지만, datacenter 전체의 손실까지는 보호하지 않습니다. 또 다른 오해는 단순히 여러 VM을 사용하는 것만으로 충분하다는 것입니다. datacenter 장애 허용을 달성하려면 VM이 여러 zone에 분산되어 있어야 합니다.
시험 팁:
- 요구 사항에 단일 datacenter 장애를 견뎌야 한다는 내용이 있으면 Availability Zones를 떠올리세요.
- 요구 사항이 한 datacenter 내의 maintenance events 또는 hardware failures에 관한 것뿐이라면 Availability Sets로 충분할 수 있습니다.
- AZ-900에서는 Availability Sets(동일 datacenter)와 Availability Zones(region 내의 서로 다른 datacenters)를 명확히 구분하세요.
7
문제 7
HOTSPOT -
중요한 기간 업무(line-of-business) 애플리케이션을 Azure에 배포할 계획입니다.
애플리케이션은 Azure virtual machine에서 실행됩니다.
애플리케이션에 대한 배포 솔루션을 권장해야 합니다. 솔루션은 99.99%의 가용성을 보장해야 합니다.
배포를 위해 권장해야 하는 virtual machine의 최소 개수와 availability zone의 최소 개수는 얼마입니까? 답하려면, 답안 영역에서 적절한 옵션을 선택하십시오.
참고: 각 정답 선택은 1점입니다.
핫 영역:
파트 1:
가상 머신의 최소 개수
가상 머신의 최소 개수: 2.
VM 기반 애플리케이션에서 99.99% 가용성 목표를 달성하려면 단일 인스턴스 배포를 피해야 합니다. VM이 1대뿐이면 계획된 유지보수, 호스트 장애, OS 크래시 또는 VM 수준 문제로 인해 애플리케이션 전체에 다운타임이 발생하므로 99.99% 보장을 충족할 수 없습니다. 동일한 워크로드를 실행하는 VM 2대(일반적으로 load balancer 뒤의 active/active 구성)를 사용하면 한 VM을 사용할 수 없게 되더라도 애플리케이션이 계속 트래픽을 처리할 수 있습니다. 이것이 compute 계층에서 중복성을 가능하게 하는 최소 인스턴스 수입니다.
왜 3이 아닌가? VM 3대는 용량을 개선하고 위험을 더 줄일 수 있지만, Azure의 표준 고가용성 패턴에서 99.99%를 충족하기 위해 필요한 최소 구성은 아닙니다. “최소”를 묻는 시험 문제는 SLA 요구 사항을 만족하는 가장 작은 아키텍처에 초점을 맞추며, 그 답은 2개 인스턴스입니다.
파트 2:
최소 availability zone 수
최소 availability zone 수: 2.
Availability Zone은 Azure region 내에 물리적으로 분리된 datacenter로, 각각 독립적인 전원, 냉각, 네트워킹을 갖습니다. zone 수준의 복원력(그리고 중요한 workload에 대해 99.99% 보장을 기대하는 일반적인 시험 기준)을 주장하려면, zone 장애가 애플리케이션을 중단시키지 않도록 최소 두 개의 zone에 걸쳐 배포해야 합니다. 1개의 zone만 사용하면 zone 중복성이 없으며, datacenter 수준에서 사실상 단일 장애 경계가 됩니다.
왜 3이 아닌가요? 3개의 zone은 복원력을 더 높일 수 있고 더 높은 fault tolerance를 위해 종종 권장되지만, 최소 요구사항은 아닙니다. 2개의 zone은 단일 zone 손실로부터 보호하면서도 남은 zone에서 애플리케이션이 계속 실행될 수 있게 하는 최소 수입니다.
8
문제 8
이 질문에서는 밑줄 친 텍스트가 올바른지 판단하기 위해 평가해야 합니다.
Azure Germany는 독일의 법적 거주자만 사용할 수 있습니다.
지침: 밑줄 친 텍스트를 검토하십시오. 해당 텍스트가 문장을 올바르게 만든다면 No change is needed를 선택하십시오. 문장이 올바르지 않다면, 문장을 올바르게 만드는 답안을 선택하십시오.
원래 문장은 Azure Germany가 독일의 법적 거주자만을 위한 서비스로 정의되지 않았기 때문에 틀렸습니다. 시험 자료에서 자격 요건의 초점은 개인의 거주 상태가 아니라 enterprises에 있었습니다. 따라서 법적 거주 여부는 잘못된 기준입니다. 문장을 그대로 두면 그 오류가 유지됩니다.
이 옵션은 독일의 법적 거주자에 대한 부정확한 문구를 Azure Germany에 대한 시험에서 기대하는 자격 기준으로 올바르게 대체합니다. 기존 AZ-900 콘텐츠에서 Azure Germany는 국적이나 거주지를 기준으로 한 개인용이 아니라 독일에 등록된 enterprises를 위한 sovereign cloud offering으로 제시되었습니다. 따라서 이 답은 개인 거주지가 아니라 조직 자격 요건을 반영하므로 가장 적합합니다. 또한 local partner를 통해 구매해야 한다는 근거 없는 요구 사항도 추가하지 않습니다.
이 옵션은 Azure Germany 액세스가 고객이 Azure licenses를 어디에서 구매했는지에 따라 결정되지 않았기 때문에 틀렸습니다. 독일의 partner를 통해 구매하는 것은 조달 세부 사항일 뿐, sovereign cloud의 핵심 자격 규칙이 아닙니다. 시험 목표에서는 독일 기반 reseller 또는 partner를 사용 조건으로 요구하지 않았습니다. 따라서 이 답은 핵심 규칙이 아닌 제한을 추가합니다.
이 옵션은 문제가 독일의 일반 Azure regions에 관한 것이라면 그럴듯하게 들릴 수 있지만, sovereign cloud offering인 Azure Germany에 대한 최선의 답은 아닙니다. Azure Germany는 단순히 독일 데이터 상주를 원한다는 이유만으로 전 세계의 모든 사용자나 enterprise가 사용할 수 있는 것이 아니었습니다. 시험에서의 구분점은 Azure Germany가 독일에 등록된 enterprises와 연결된 더 좁은 자격 모델을 가졌다는 것이었습니다. 따라서 이 옵션은 액세스를 지나치게 일반화하므로 올바른 대체 문구가 아닙니다.
문제 분석
핵심 개념:
이 문제는 표준 Azure public regions와 구별되는 특별한 sovereign cloud offering이었던 Azure Germany에 대한 지식을 테스트합니다. 핵심 포인트는 Azure Germany가 독일의 법적 거주자에게만 제한된 것이 아니었지만, 단순히 독일 데이터 상주를 선호한다는 이유만으로 어디의 고객이든 사용할 수 있었던 것도 아니라는 점입니다.
정답인 이유:
정답 대체 문구는 Azure Germany를 독일에 등록된 enterprises만 사용할 수 있다는 것입니다. 이는 Azure Germany 자격 요건이 개인의 법적 거주자 여부나 구매 채널 요구 사항보다는 독일에 등록된 조직에 초점을 두었던 이전 AZ-900 시험 목표 언어와 일치합니다.
주요 특징:
- Azure Germany는 독일의 데이터 상주 및 규정 준수 기대 사항을 충족하도록 설계된 별도의 cloud environment였습니다.
- 이는 개인의 시민권이나 법적 거주 상태로 제한되지 않는 business 및 organizational use case를 위한 것이었습니다.
- 시험 맥락에서 자격 요건은 독일 내 enterprise 등록과 연결되어 있었으며, 독일 partner를 통해 구매하는 것과는 관련이 없었습니다.
일반적인 오해:
- Azure Germany를 workload 배치를 위해 선택하는 독일의 일반 Azure regions와 혼동하는 것.
- 단지 데이터를 독일에 저장하고 싶다는 이유만으로 어떤 고객이든 Azure Germany를 사용할 수 있다고 가정하는 것.
- 독일 기반 licensing partner를 통해 구매해야 액세스할 수 있다고 믿는 것.
시험 팁:
- Azure Germany를 표준 Azure public regions와 구분하는 오래된 AZ-900 문제를 주의해서 보세요.
- 문구에 Azure Germany가 구체적으로 언급되면, 일반적인 regional deployment가 아니라 sovereign cloud 자격 요건을 떠올리세요.
- 서비스가 이를 명시적으로 요구하지 않는 한, 시민권, 거주지 또는 partner channel에 기반한 답은 제거하세요.
9
문제 9
Windows Server 2016을 실행하는 VM1이라는 가상 머신이 있습니다. VM1은 East US Azure 지역에 있습니다.
Azure portal에서 VM1의 가용성에 영향을 줄 수 있는 서비스 장애 알림을 보려면 어떤 Azure 서비스를 사용해야 합니까?
Azure Service Fabric은 마이크로서비스 및 컨테이너화된 애플리케이션을 빌드하고 실행하기 위한 분산 시스템 플랫폼입니다. 애플리케이션 신뢰성과 오케스트레이션에는 도움이 되지만, 특정 지역의 VM에 대한 Azure 플랫폼 서비스 장애 알림을 제공하지는 않습니다. VM1에 영향을 주는 Azure 서비스 인시던트 또는 계획된 유지 관리 이벤트를 보기 위한 도구가 아닙니다.
Azure Monitor는 Azure의 중앙 모니터링 서비스이며 portal 경험에서 Azure Service Health를 포함하므로 올바른 선택입니다. Service Health는 특정 지역(East US) 및 구독의 리소스에 영향을 줄 수 있는 서비스 이슈 알림, 계획된 유지 관리, 상태 권고를 제공합니다. 또한 이러한 이벤트에서 경고를 구성하여 관리자가 사전에 알림을 받도록 할 수 있습니다.
Azure virtual machines 서비스(또는 VM 리소스 블레이드)는 VM1을 관리(시작/중지, 크기 조정, 디스크, 네트워킹)하고 VM 수준 메트릭 및 로그를 보는 곳입니다. 일부 VM 상태 정보를 볼 수는 있지만, 지역 또는 기본 플랫폼에 영향을 주는 Azure 전반의 서비스 장애 알림과 계획된 유지 관리를 확인하는 기본 portal 위치는 아닙니다.
Azure Advisor는 cost, security, reliability, performance, operational excellence 전반에 걸친 모범 사례 권장 사항을 제공합니다. 복원력을 개선하기 위한 조치(예: availability zones 사용)를 제안할 수는 있지만, East US의 VM1에 영향을 주는 실시간 서비스 장애 알림 또는 계획된 유지 관리 이벤트를 확인하기 위한 주요 인터페이스로 설계된 것은 아닙니다.
문제 분석
핵심 개념:
이 문제는 리소스의 가용성에 영향을 줄 수 있는 Azure 플랫폼 상태 이벤트를 모니터링하는 방법을 평가합니다. Azure에서 서비스 장애 알림(계획된 유지 관리, 예기치 않은 중단, 상태 권고)은 Azure Service Health를 통해 제공되며, Azure portal에서는 Azure Monitor를 통해 액세스하고 조치합니다.
정답인 이유:
Azure portal에서 Azure Monitor는 모니터링 및 경고의 허브입니다. Azure Monitor 내에서 Service Health에 액세스하여 구독 및 지역(예: East US)에 영향을 주는 서비스 이슈와 계획된 유지 관리를 확인하고, 이러한 이벤트가 VM1 같은 리소스에 어떤 영향을 줄 수 있는지 볼 수 있습니다. 또한 Azure Monitor를 사용하면 Service Health 이벤트를 기반으로 경고(email/SMS/webhook/ITSM)를 생성하여, 인시던트 또는 유지 관리 이벤트가 VM 가용성에 영향을 줄 수 있을 때 사전에 알림을 받을 수 있습니다.
주요 기능 및 모범 사례:
Azure Monitor + Service Health는 다음을 제공합니다:
- Service issues: Azure 서비스에서 발생하는 예기치 않은 중단 또는 성능 저하.
- Planned maintenance: VM 재부팅이 필요하거나 짧은 중단을 유발할 수 있는 예약된 업데이트.
- Health advisories: 중요한 공지(예: 보안 또는 성능 가이드).
Azure Well-Architected Framework(Reliability)와 일치하는 모범 사례: 중요한 지역 및 구독에 대해 Service Health 경고를 구성하고, 인시던트 관리와 통합하며, 복원력(availability zones, region pairs, backups)을 고려해 설계하여 단일 지역 이벤트의 영향을 줄입니다.
흔한 오해:
많은 학습자가 “Azure Advisor”를 중단 알림과 혼동합니다. Advisor는 권장 사항(cost, security, reliability, operational excellence)을 제공하지만, 실시간 플랫폼 인시던트를 확인하는 기본 위치는 아닙니다. 또 다른 선택지로 “Azure virtual machines”를 고르는 경우가 있는데, VM 블레이드에서 일부 상태 정보를 볼 수는 있지만 플랫폼 전반의 서비스 장애 알림을 포괄적으로 제공하지는 않습니다. “Service Fabric”은 애플리케이션 플랫폼이며 Azure 플랫폼 상태 알림과는 관련이 없습니다.
시험 팁:
AZ-900에서는 다음을 기억하세요: 플랫폼 인시던트/유지 관리 알림 = Azure Service Health(Azure Monitor 아래에서 찾음). 문제가 “notifications”, “outages”, “planned maintenance”, “region/service issues”를 언급하면 Advisor나 리소스 블레이드가 아니라 Service Health/Monitor를 떠올리세요.
10
문제 10
코드를 관리하기 위한 버전 관리 도구 세트를 제공하는 Azure 서비스는 무엇입니까?
Azure Repos는 source control을 위한 Azure DevOps 서비스입니다. Git repositories와 TFVC를 제공하여 팀이 branching, merging, pull requests, code reviews, access controls로 코드를 관리할 수 있게 합니다. CI/CD를 위한 Azure Pipelines와 긴밀하게 통합되며 branch policies(예: 필수 리뷰어 및 build validation)를 통해 거버넌스를 지원하므로, 버전 관리 도구에 대한 올바른 선택입니다.
Azure DevTest Labs는 개발/테스트 환경(종종 사전 구성된 VM images 사용)을 정책과 함께 생성, 관리, 제어하여 비용을 줄이고 일관성을 높이는 데 사용됩니다. 팀이 lab 리소스를 빠르게 프로비저닝하고 quotas 및 schedules를 적용하도록 돕지만, repositories, branching, pull requests 같은 버전 관리 기능은 제공하지 않습니다.
Azure Storage는 비정형 및 정형 데이터를 위한 확장 가능한 스토리지 서비스(Blob, File, Queue, Table)를 제공합니다. Blob Storage에 코드 파일을 저장할 수는 있지만, commit history, branching/merging, pull requests, 또는 code review 워크플로 같은 버전 관리 기능은 제공하지 않습니다. 이는 스토리지 플랫폼이지 source control 시스템이 아닙니다.
Azure Cosmos DB는 낮은 지연 시간과 높은 가용성을 갖춘 애플리케이션 데이터를 위해 설계된 전 세계 분산, multi-model NoSQL database입니다. NoSQL, MongoDB, Cassandra, Gremlin, Table 같은 APIs를 지원합니다. 소스 코드를 관리하거나 버전 관리 워크플로를 제공하기 위한 용도가 아니므로, 질문의 요구사항을 충족하지 않습니다.
문제 분석
핵심 개념:
이 문제는 Azure DevOps 서비스, 특히 코드를 관리하기 위한 버전 관리(source control) 도구를 제공하는 구성 요소를 식별하는지를 평가합니다. Azure에서 버전 관리는 일반적으로 Azure DevOps를 통해 제공되며, Azure DevOps에는 Azure Repos, Azure Pipelines, Azure Boards, Azure Test Plans, Azure Artifacts가 포함됩니다.
정답이 맞는 이유:
Azure Repos는 코드를 관리하기 위한 버전 관리 도구 세트를 제공하는 Azure DevOps 서비스입니다. Git repositories(분산 버전 관리)와 Team Foundation Version Control(TFVC, 중앙 집중식 버전 관리)을 모두 지원합니다. 이는 “코드를 관리하기 위한 버전 관리 도구 세트”라는 요구사항과 직접적으로 일치합니다. 실제 DevOps 워크플로에서 Azure Repos는 팀이 소스 코드를 저장하고, 브랜치를 관리하며, pull requests를 수행하고, (필수 리뷰어 같은) 정책을 적용하고, CI/CD pipelines와 통합하는 곳입니다.
주요 기능 및 모범 사례:
Azure Repos는 Git/TFVC hosting, branch policies, code reviews가 포함된 pull requests, repository permissions, 그리고 자동화된 빌드 및 배포를 위한 Azure Pipelines와의 통합을 제공합니다. 모범 사례로는 팀 요구에 따라 명확한 branching strategy(예: trunk-based development 또는 GitFlow)를 사용하고, branch policies(build validation, 최소 리뷰어 수)를 강제하며, pull requests를 사용해 코드 품질과 보안을 개선하는 것이 있습니다. 이러한 실천은 Operational Excellence(반복 가능한 프로세스, 자동화) 및 Security(통제된 변경, least privilege)와 같은 Azure Well-Architected Framework 원칙을 지원합니다.
흔한 오해:
Azure DevTest Labs는 개발자 중심으로 들리지만, source control이 아니라 dev/test environments(VMs, lab policies, cost controls)를 생성하고 관리하기 위한 서비스입니다. Azure Storage는 파일/블롭을 저장할 수 있지만, branching, merging, pull requests 같은 버전 관리 워크플로를 제공하지 않습니다. Azure Cosmos DB는 애플리케이션 데이터를 위한 전 세계 분산 NoSQL database이며, 코드 관리를 위한 것이 아닙니다.
시험 팁:
AZ-900에서는 “version control/source control”을 Azure DevOps, 그중에서도 특히 Azure Repos에 매핑하세요. “CI/CD”는 Azure Pipelines, “work tracking”은 Azure Boards, “packages”는 Azure Artifacts에 매핑합니다. 질문에 Git repos, pull requests, 또는 branch policies가 언급되면 정답은 거의 항상 Azure Repos입니다.
