모든 답안은 3개의 최고 AI 모델로 교차 검증하여 최고의 정확도를 보장합니다. 선택지별 상세 해설과 심층 문제 분석을 제공합니다.
GPT Pro
Claude Opus
Gemini Pro
선택지별 상세 해설
심층 문제 분석
3개 모델 합의 정확도
연습 문제
1
문제 1
회사에는 다음 표에 표시된 인프라가 있습니다.
on-premises Active Directory domain은 Azure Active Directory (Azure AD)와 동기화됩니다.
Server1은 on-premises Active Directory domain에서 사용자 ID를 확인하기 위해 LDAP 쿼리를 사용하는 App1이라는 애플리케이션을 실행합니다.
Server1을 Subscription1의 virtual machine으로 마이그레이션할 계획입니다.
회사 보안 정책에 따르면 Subscription1에 배포된 virtual machine 및 서비스는 on-premises network에 액세스하지 못하도록 차단되어야 합니다.
마이그레이션 후에도 App1이 계속 작동하도록 보장하는 솔루션을 권장해야 합니다. 솔루션은 보안 정책을 충족해야 합니다.
권장 사항에 무엇을 포함해야 합니까?
파트 1:
위치: Azure - 리소스: Subscription1이라는 이름의 Azure subscription
아니요. Azure subscription은 청구 및 관리 경계일 뿐이며, App1에 LDAP를 제공하는 서비스가 아닙니다. 애플리케이션이 계속 작동하도록 하려면, 마이그레이션된 VM이 on-premises network에 대한 어떤 연결 없이도 LDAP를 쿼리할 수 있도록 Azure에 Azure AD Domain Services를 배포해야 합니다. Yes라고 답하는 것은 배포 위치와 솔루션에 실제로 필요한 리소스를 혼동하는 것입니다. subscription은 솔루션을 호스팅할 수는 있지만, 그 자체가 권장 구성 요소로 포함해야 하는 것은 아닙니다.
파트 2:
위치: Azure - 리소스: 20개의 Azure web apps
아니요. Azure web apps는 directory services 또는 LDAP endpoints를 제공하지 않으므로, migration 후에도 App1이 LDAP queries를 계속 수행하는 데 도움이 되지 않습니다. 요구 사항은 Azure에서 on-premises network로의 액세스를 방지하면서 LDAP 기반 authentication을 유지하는 것이며, 이는 App Service가 아니라 Azure AD Domain Services로 해결됩니다. 20개의 Azure web apps에 대한 언급은 migrated server workload와 관련이 없습니다. 따라서 이 리소스는 권장 사항에 포함되어서는 안 됩니다.
파트 3:
위치: On-premises datacenter - 리소스: Active Directory domain
아니요. 마이그레이션된 애플리케이션은 On-premises Active Directory domain에 의존해서는 안 됩니다. Subscription1 리소스는 On-premises network에 액세스할 수 없기 때문입니다. On-premises AD DS는 원래의 identity source로 유지되고 Azure AD로 계속 동기화될 수 있지만, 마이그레이션 후 App1의 runtime solution에는 포함되지 않습니다. Azure의 Azure AD Domain Services는 Azure 내에서 로컬로 필요한 LDAP 기능을 제공합니다. 따라서 On-premises Active Directory domain은 권장 사항에 포함되어서는 안 됩니다.
파트 4:
위치: On-premises datacenter - 리소스: Azure AD Connect를 실행하는 서버
예. Azure AD Connect는 on-premises Active Directory domain의 identity를 Azure AD로 동기화하고, 이후 Azure AD Domain Services를 채우는 데 사용되므로 포함되어야 합니다. App1은 Azure의 Azure AD Domain Services에 대해 인증하지만, 해당 managed domain은 Azure AD에 동기화된 identity가 존재하는 것에 의존합니다. Azure AD Connect 자체가 LDAP를 제공하지는 않지만, end-to-end solution에서 여전히 필요한 구성 요소입니다. 아니요라고 답하면 Azure AD Domain Services에 필요한 사용자 및 그룹이 포함되도록 하는 identity synchronization 경로를 간과하게 됩니다.
파트 5:
위치: On-premises datacenter - 리소스: Server1이라는 이름의 Linux 컴퓨터
아니요. Server1이라는 이름의 on-premises Linux 컴퓨터는 마이그레이션되는 원본 서버이며, 최종적으로 권장되는 솔루션의 일부로 남아 있는 리소스가 아닙니다. 요구 사항은 App1이 Azure virtual machine으로 이동된 후에도 계속 작동하도록 보장하면서 on-premises network에 대한 액세스를 방지하는 것입니다. 필요한 구성 요소는 Azure의 Azure AD Domain Services와 기존 identity synchronization 경로이며, 원래의 on-premises 서버가 아닙니다. Yes라고 답하면 원본 머신을 마이그레이션 후 아키텍처의 일부로 잘못 간주하게 됩니다.
이동 중에도 모든 문제를 풀고 싶으신가요?
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
Cloud Pass를 다운로드하고 모든 Microsoft AZ-305 학습 문제를 무료로 이용하세요.
이동 중에도 모든 문제를 풀고 싶으신가요?
무료 앱 받기
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
2
문제 2
온-프레미스 네트워크와 Azure 구독이 있습니다. 온-프레미스 네트워크에는 여러 지사 사무실이 있습니다.
Toronto의 한 지사 사무실에는 파일 서버로 구성된 VM1이라는 virtual machine이 있습니다. 사용자는 모든 사무실에서 VM1의 공유 파일에 액세스합니다.
Toronto 지사 사무실에 액세스할 수 없게 되는 경우에도 사용자가 공유 파일에 가능한 한 빠르게 액세스할 수 있도록 보장하는 솔루션을 권장해야 합니다.
권장 사항에 무엇을 포함해야 합니까?
Recovery Services vault와 Windows Server Backup은 주로 backup/restore 접근 방식입니다. VM1의 데이터를 보호할 수는 있지만, Toronto outage 중에는 사용자가 즉시 액세스할 수 없습니다. 먼저 대체 인프라로 restore해야 합니다. 이는 RTO를 증가시키며 지사 사무실 전반의 사용자 액세스 속도를 본질적으로 향상시키지 않습니다. 이는 빠르고 지속적인 파일 액세스가 아니라 데이터 보호를 해결합니다.
Azure blob containers와 Azure File Sync는 이 사용 사례에 적합한 조합이 아닙니다. Azure File Sync는 cloud endpoint로 Blob storage가 아니라 Azure file share(Azure Files)를 필요로 합니다. Blob은 object storage 및 archival에는 매우 적합하지만, 추가 서비스/gateway 없이는 일반적인 Windows file server 공유 폴더에 필요한 SMB share semantics를 제공하지 않습니다.
Recovery Services vault와 Azure Backup은 VM1을 보호하고 Azure 또는 다른 서버로 데이터를 restore할 수 있지만, 여전히 restore 기반 DR 방법입니다. 이미 대체 파일 서버를 프로비저닝하고 동기화해 두지 않았다면 outage 중 사용자는 공유 파일에 빠르게 액세스할 수 없습니다. 이 옵션은 내구성을 향상시키지만, 일반적으로 동기화된 cloud-backed file share 솔루션에 비해 더 높은 RTO를 초래합니다.
Azure file share와 Azure File Sync를 함께 사용하면 multi-site caching이 가능한 cloud-backed 파일 시스템을 구현할 수 있습니다. VM1은 Azure Files와 동기화할 수 있고, 다른 사무실은 낮은 지연 시간 액세스를 위해 로컬 캐시 복사본을 유지하는 File Sync server endpoint를 호스팅할 수 있습니다. Toronto가 다운되면 사용자를 다른 endpoint 또는 직접 Azure Files로 리디렉션할 수 있으므로 backup/restore보다 훨씬 빠른 액세스를 제공하며 복원력 목표를 충족합니다.
문제 분석
핵심 개념:
이 문제는 지사 사무실(Toronto)을 사용할 수 없게 되었을 때 공유 파일 액세스를 위한 고가용성/DR 접근 방식을 설계하는지를 평가합니다. 핵심은 단순히 데이터를 복원하는 것이 아니라, 여러 사무실의 사용자가 빠르고 지속적으로 액세스할 수 있도록 유지하는 것입니다. 이는 Azure Well-Architected Framework의 reliability(복원력, failover) 및 performance efficiency(낮은 지연 시간 액세스)와 일치합니다.
정답인 이유:
Azure file share(Azure Files)와 Azure File Sync를 사용하면 cloud-backed, multi-site-capable 파일 솔루션을 제공할 수 있습니다. Azure File Sync는 Toronto 파일 서버(VM1)를 Azure file share와 동기화할 수 있으며, 다른 사무실에 추가 File Sync server endpoint(cache server)를 배포할 수 있습니다. Toronto에 액세스할 수 없게 되면 사용자를 다른 로컬 server endpoint(또는 직접 Azure Files)로 리디렉션할 수 있으며, 해당 endpoint에는 이미 namespace와 캐시된 데이터가 있으므로 restore 기반 접근 방식보다 훨씬 빠른 액세스를 제공할 수 있습니다. Azure file share는 Azure에서 데이터의 중앙 집중식 고가용성 복사본이 됩니다.
주요 기능 및 모범 사례:
- Azure Files는 여러 위치에서 액세스 가능한 SMB 기반 공유를 제공합니다. 내구성을 향상시키기 위해 redundancy 옵션(예: region/account type에 따라 ZRS/GRS)을 지원합니다.
- Azure File Sync는 다음을 제공합니다:
- Cloud endpoint(Azure file share) + server endpoints(Windows Servers)를 통한 multi-site caching.
- Cloud tiering을 통해 hot data는 로컬에 유지하고 cold data는 Azure로 오프로드.
- 액세스의 신속한 복구: primary site가 다운되더라도 다른 사무실이 로컬 cache에서 계속 파일을 제공할 수 있습니다.
- 최상의 성능을 위해 대다수 사용자에 대한 지연 시간을 최소화하는 region에 storage account를 배치하고, 예측 가능한 연결을 위해 ExpressRoute/VPN을 사용합니다.
일반적인 오해:
Backup 솔루션(Azure Backup/Windows Server Backup)은 데이터를 보호하지만 outage 중 즉각적이고 낮은 지연 시간의 액세스를 제공하지는 않습니다. 이러한 솔루션은 restore 작업과 데이터 rehydrate 시간이 필요합니다. Blob containers는 object storage이며 일반적인 Windows file server 워크로드에 필요한 SMB file share semantics를 기본적으로 제공하지 않습니다.
시험 팁:
- 요구 사항이 “site outage 중 파일에 빠르게 액세스”라면 backup/restore보다 active/active 또는 cloud-backed 파일 서비스(Azure Files + Azure File Sync)를 우선 고려하십시오.
- Azure File Sync는 로컬에서 Windows file server 호환성을 유지하면서 Azure에 데이터를 중앙 집중화하고 multi-branch caching을 가능하게 하려는 경우의 대표적인 선택입니다.
- 요구 사항 매핑: “액세스할 수 없는 site” + “빠른 액세스” => 단순한 데이터 보호가 아니라 복원력 + caching입니다.
3
문제 3
HOTSPOT -
machine learning 애플리케이션을 지원하기 위해 Azure Databricks를 배포할 계획입니다. Data engineer는 Azure Data Lake Storage 계정을 Databricks file system에 mount합니다. 폴더에 대한 권한은 data engineer에게 직접 부여됩니다.
계획된 Databrick 배포를 위한 설계를 권장해야 합니다. 솔루션은 다음 요구 사항을 충족해야 합니다:
✑ Data engineer가 권한이 있는 폴더에만 액세스할 수 있도록 보장합니다.
✑ 개발 노력을 최소화합니다.
✑ 비용을 최소화합니다.
권장 사항에 무엇을 포함해야 합니까? 답하려면 답안 영역에서 적절한 옵션을 선택하세요.
참고: 각 정답 선택에는 1점이 부여됩니다.
Hot Area:
파트 1:
Databricks SKU: ______
Databricks credential passthrough는 Premium 기능이므로 Premium을 선택합니다. 요구 사항에 따르면 권한은 data engineers에게 직접(사용자별) 부여되며, 각 사용자는 자신에게 권한이 있는 폴더에만 액세스해야 합니다. 이를 ADLS Gen2 ACLs로 강제하려면 Databricks가 개별 사용자의 Azure AD identity를 사용하여 ADLS에 액세스해야 하며, 이는 credential passthrough를 통해 활성화됩니다.
Standard SKU는 일반적으로 mounts에 대해 공유 credentials(storage account key/service principal를 secrets를 통해 사용)에 의존하므로, cluster의 모든 사용자가 공유 identity가 액세스할 수 있는 모든 항목에 액세스할 수 있게 됩니다. 이는 복잡한 우회 방법(여러 mounts, 별도의 containers, custom authorization logic)을 구현하지 않는 한 사용자별 폴더 제한을 위반하게 됩니다. Premium은 Standard보다 비용이 증가하지만, 최소한의 개발 노력으로 보안 요구 사항을 충족하는 데 필요한 SKU이며 least-privilege access control에도 부합합니다.
파트 2:
클러스터 구성: ______
Credential passthrough를 선택합니다. 이 구성은 Databricks가 로그인한 사용자의 Azure AD identity를 ADLS Gen2에 전달하여, ADLS가 사용자별로 folder/file ACL을 평가할 수 있게 합니다. 이는 다음 요구 사항을 직접 충족합니다: “data engineer가 권한이 있는 folder에만 액세스할 수 있도록 보장합니다.” 또한 custom access control을 구축하는 대신 기본 Azure AD + ADLS ACL enforcement에 의존하므로 개발 노력을 최소화합니다.
다른 선택지가 틀린 이유: Managed identities는 일반적으로 단일 workload identity(cluster/job)에 사용되며, 여러 engineer가 하나의 cluster를 공유할 때 사용자별 권한을 본질적으로 적용하지 않습니다. Secret scopes는 공유 secret(예: service principal credential)을 저장하며, 이 경우에도 공유 액세스로 이어집니다. MLflow와 Photon runtime은 성능/ML 기능이지 access control 기능이 아닙니다. 따라서 사용자별 authorization을 위한 올바른 cluster 구성은 credential passthrough입니다.
4
문제 4
참고: 이 문제는 동일한 시나리오를 제시하는 일련의 문제 중 일부입니다. 시리즈의 각 문제에는 제시된 목표를 충족할 수 있는 고유한 솔루션이 포함되어 있습니다. 일부 문제 세트에는 둘 이상의 올바른 솔루션이 있을 수 있지만, 다른 문제 세트에는 올바른 솔루션이 없을 수도 있습니다.
이 섹션의 문제에 답한 후에는 해당 문제로 돌아갈 수 없습니다. 따라서 이러한 문제는 검토 화면에 표시되지 않습니다.
귀사는 여러 virtual machine을 온-프레미스와 Azure에 배포합니다. 온-프레미스와 Azure 간 연결을 위해 ExpressRoute가 배포되고 구성되어 있습니다.
여러 virtual machine에서 네트워크 연결 문제가 발생합니다.
virtual machine에 대한 packet이 허용되는지 또는 거부되는지 식별하기 위해 네트워크 트래픽을 분석해야 합니다.
솔루션: Azure Advisor를 사용하여 네트워크 트래픽을 분석합니다.
이것이 목표를 충족합니까?
예는 오답입니다. Azure Advisor는 네트워크 packet flow를 캡처하거나 분석하지 않으며 VM 트래픽에 대한 허용/거부 결정을 제공하지 않기 때문입니다. Advisor는 운영 트래픽 진단이 아니라 모범 사례 권장 사항(비용 최적화, 보안 상태, 안정성, 성능)에 중점을 둡니다. 개선 사항을 제안할 수는 있지만, 특정 packet이 허용되었는지 또는 거부되었는지는 알려줄 수 없습니다.
아니요가 정답인 이유는 Azure Advisor가 packet 수준의 네트워크 트래픽을 분석하거나 virtual machine으로 향하는 특정 트래픽이 허용되었는지 또는 거부되었는지를 판단하지 않기 때문입니다. Advisor는 리소스 최적화 및 모범 사례에 대한 상위 수준의 권장 사항을 제공하지만, flow 수준의 연결 문제 해결을 위한 용도로 설계되지 않았습니다. packet이 허용되는지 또는 차단되는지를 식별하려면 IP flow verify, NSG flow logs, packet capture와 같은 Azure Network Watcher 도구가 적절한 서비스입니다. 이러한 도구는 ExpressRoute로 연결된 환경이 포함된 시나리오를 포함하여 Azure virtual machine의 연결 문제를 진단하는 데 도움이 될 수 있습니다.
문제 분석
핵심 개념:
이 문제는 Azure 네트워킹 모니터링 및 진단 도구에 대한 지식을 평가합니다. 요구 사항은 ExpressRoute로 연결된 hybrid 환경을 포함하여, virtual machine으로 향하는 packet이 허용되는지 또는 거부되는지를 판단하기 위해 네트워크 트래픽을 분석하는 것입니다.
정답인 이유:
이 솔루션은 목표를 충족하지 않습니다. Azure Advisor는 packet 수준 또는 flow 수준의 트래픽 분석 도구가 아니기 때문입니다. 트래픽이 허용되는지 또는 거부되는지를 식별하려면 IP flow verify, NSG flow logs, connection troubleshoot, packet capture를 포함한 Azure Network Watcher와 같은 도구를 사용해야 합니다. 이러한 도구는 연결 문제를 진단하고 보안 규칙이 트래픽을 허용하는지 차단하는지 평가하도록 설계되었습니다.
주요 기능:
Azure Advisor는 비용, 보안, 안정성, 운영 우수성 및 성능에 대한 모범 사례 권장 사항을 제공합니다. 실시간 packet flow를 검사하거나, 특정 트래픽에 대한 NSG 결정을 평가하거나, 문제 해결을 위해 packet을 캡처하지는 않습니다. Azure에서 VM 네트워크 트래픽 동작을 분석하는 데 적절한 서비스는 Azure Network Watcher입니다.
일반적인 오해:
흔한 실수는 Azure Advisor가 Azure 리소스에 대한 권장 사항을 표시하므로 운영 진단도 수행할 수 있다고 가정하는 것입니다. 실제로 Advisor는 권장 사항 엔진이지, 트래픽 검사 또는 packet 분석 서비스가 아닙니다. 또 다른 오해는 ExpressRoute 연결 문제가 네트워크 진단 도구가 아니라 거버넌스 또는 advisory 도구를 통해 진단된다고 생각하는 것입니다.
시험 팁:
AZ-305에서 트래픽이 허용되는지 또는 거부되는지를 묻는 문제를 보면 IP flow verify 및 NSG flow logs와 같은 Azure Network Watcher 기능을 떠올리십시오. 권장 사항이나 최적화 지침을 묻는다면 Azure Advisor를 떠올리십시오. advisory 서비스와 diagnostic 서비스를 명확히 구분하십시오.
5
문제 5
온-프레미스 datacenter에서 App1이라는 이름의 web app을 Azure로 이전할 계획입니다.
App1은 host server에 설치된 사용자 지정 COM component에 종속됩니다.
Azure에서 App1을 호스팅하기 위한 솔루션을 권장해야 합니다. 이 솔루션은 다음 요구 사항을 충족해야 합니다:
✑ Azure datacenter를 사용할 수 없게 되더라도 App1은 사용자에게 계속 제공되어야 합니다.
✑ 비용은 최소화되어야 합니다.
권장 사항에 무엇을 포함해야 합니까?
Azure Web Apps는 App Service에서 실행되며, server에 사용자 지정 COM component를 설치하고 등록하는 데 필요한 host 수준 액세스를 제공하지 않습니다. 두 개의 region에 배포하면 복원력은 향상되지만, 플랫폼 자체가 애플리케이션의 종속성과 호환되지 않습니다. load balancer도 이러한 제한을 바꾸지는 못합니다. 따라서 이 옵션은 핵심 기술 요구 사항을 충족하지 못합니다.
virtual machine scale set은 OS 수준 제어를 제공하므로 사용자 지정 COM component를 지원하지만, 두 개의 region에 배포하는 것은 명시된 요구 사항에 비해 비용이 더 많이 듭니다. 문제는 Azure datacenter를 사용할 수 없게 되는 경우의 가용성을 요구하며, 이는 단일 region 내의 Availability Zones로 해결하는 것이 가장 적절합니다. 두 region 배포는 중복 인프라, networking 및 운영 복잡성을 추가합니다. 비용을 최소화해야 하므로, 이것이 최선의 권장 사항은 아닙니다.
virtual machine scale set은 guest operating system을 완전히 제어할 수 있어 사용자 지정 COM component를 설치하고 유지 관리할 수 있으므로 올바른 호스팅 선택입니다. scale set을 두 개의 availability zone에 걸쳐 배포하면 zones가 물리적으로 분리된 datacenter이므로 region 내의 하나의 Azure datacenter에 장애가 발생하더라도 애플리케이션이 계속 사용 가능합니다. Azure Load Balancer는 두 zones 모두의 정상 상태 VM 인스턴스들에 트래픽을 분산할 수 있습니다. 또한 이 설계는 애플리케이션을 두 개의 별도 region에 중복 배포하는 것보다 비용을 최소화합니다.
Traffic Manager와 두 개 region의 web apps 조합은 multi-region web applications를 위한 유효한 패턴이지만, 여전히 호스팅에 App Service를 사용합니다. App Service는 기본 server에 임의의 COM components를 설치해야 하는 애플리케이션을 호스팅할 수 없습니다. Traffic Manager는 DNS 기반 routing 및 failover만 처리하며, 호스팅 호환성 문제를 해결하지는 못합니다. 따라서 이 옵션은 애플리케이션의 종속성 요구 사항을 충족하지 못합니다.
문제 분석
핵심 개념:
이 문제는 host 수준 종속성이 있는 애플리케이션에 적합한 Azure 호스팅 모델과 datacenter 장애에 대한 적절한 복원력 범위를 선택하는지를 평가합니다. App1은 host server에 설치된 사용자 지정 COM component에 종속되므로, 솔루션은 Azure App Service가 아니라 virtual machines 또는 virtual machine scale set과 같이 사용자가 제어할 수 있는 인프라를 사용해야 합니다. Azure datacenter를 사용할 수 없게 되더라도 계속 사용 가능하도록 하려면, 설계는 동일한 region 내의 서로 다른 물리적 datacenter에 인스턴스를 배치하는 Availability Zones에 걸쳐 있어야 합니다.
정답인 이유:
옵션 C가 가장 적합합니다. virtual machine scale set은 Windows VMs에 필요한 COM component를 설치하고 유지 관리할 수 있도록 지원하며, 두 개의 availability zone에 걸쳐 배포하면 단일 datacenter 장애로부터 보호할 수 있습니다. 또한 이는 전체 애플리케이션 스택을 두 개의 별도 Azure region에 중복 배포하는 것보다 비용을 최소화합니다. load balancer는 zonal 배포에서 정상 상태의 VM 인스턴스들에 트래픽을 분산할 수 있습니다.
주요 기능:
- VM Scale Sets는 COM components 설치를 위한 OS 수준 제어를 제공하고 autoscaling을 지원합니다.
- Availability Zones는 region 내에서 datacenter 수준의 장애 격리를 제공합니다.
- Azure Load Balancer는 서로 다른 zones의 인스턴스들에 트래픽을 분산합니다.
- 이 설계는 일반적으로 두 개 region에 active 배포하는 것보다 비용이 더 적게 듭니다.
일반적인 오해:
- Azure App Service는 종종 더 저렴하고 관리가 쉽지만, host에 임의의 COM components를 설치할 수는 없습니다.
- multi-region 배포는 단일 datacenter 장애가 아니라 regional disaster recovery를 위한 것입니다.
- Availability Sets와 Zones는 서로 바꿔 쓸 수 없으며, zones는 물리적인 datacenter 분리를 제공합니다.
시험 팁:
문제에서 사용자 지정 COM components, drivers 또는 host에 설치되는 software가 언급되면 PaaS보다 IaaS를 우선 고려하십시오. 요구 사항에 datacenter를 사용할 수 없게 된다고 되어 있으면, 문제에서 region을 사용할 수 없게 된다고 명시적으로 말하지 않는 한 Availability Zones를 떠올리십시오. 또한 multi-region은 일반적으로 zonal redundancy보다 더 비싸므로 복원력 범위와 비용을 함께 비교하십시오.
6
문제 6
참고: 이 문제는 동일한 시나리오를 제시하는 일련의 문제 중 일부입니다. 시리즈의 각 문제에는 제시된 목표를 충족할 수 있는 고유한 솔루션이 포함되어 있습니다. 일부 문제 세트에는 둘 이상의 올바른 솔루션이 있을 수 있지만, 다른 문제 세트에는 올바른 솔루션이 없을 수도 있습니다.
이 섹션의 문제에 답한 후에는 해당 문제로 돌아갈 수 없습니다. 따라서 이러한 문제는 검토 화면에 표시되지 않습니다.
Azure 구독에서 stateless web app을 호스팅하기 위한 리소스를 배포해야 합니다. 솔루션은 다음 요구 사항을 충족해야 합니다:
✑ 전체 .NET framework에 대한 액세스를 제공해야 합니다.
✑ Azure region에 장애가 발생하는 경우 redundancy를 제공해야 합니다.
✑ custom application dependencies를 설치할 수 있도록 관리자에게 operating system에 대한 액세스를 부여해야 합니다.
솔루션: 두 개의 Azure virtual machines를 두 개의 Azure regions에 배포하고, Azure Application Gateway를 배포합니다.
이것이 목표를 충족합니까?
예는 오답입니다. 두 region에 VMs가 있다는 사실만으로는 regional failover가 보장되지 않기 때문입니다. Azure Application Gateway는 regional service이므로, 단일 인스턴스는 호스팅 region을 사용할 수 없게 되면 계속해서 traffic을 제공할 수 없습니다. VM 선택은 전체 .NET Framework 및 OS administration 요구 사항을 충족하지만, 아키텍처는 여전히 ingress layer에서 단일 regional dependency를 가지고 있습니다. 올바른 multi-region 설계에는 일반적으로 regional back-end components와 함께 Azure Front Door 또는 Traffic Manager와 같은 global load-balancing service가 필요합니다.
아니요가 정답인 이유는 이 솔루션이 요구 사항을 부분적으로만 충족하기 때문입니다. 두 region의 두 Azure virtual machines는 전체 .NET Framework에 대한 액세스를 제공하고, 관리자가 operating system에 액세스하여 custom dependencies를 설치할 수 있게 합니다. 그러나 단일 Azure Application Gateway는 하나의 region에만 배포되므로, 해당 region에 장애가 발생하면 application의 entry point도 함께 장애가 발생합니다. traffic-routing layer가 region-redundant하지 않기 때문에, 전체 솔루션은 Azure region에 장애가 발생할 경우 redundancy를 제공해야 한다는 요구 사항을 충족하지 못합니다.
문제 분석
핵심 개념:
이 문제는 IaaS 기반 web application 아키텍처가 특정 호스팅 요구 사항(전체 .NET Framework 지원, region redundancy, 그리고 custom dependencies 설치를 위한 operating system에 대한 관리자 액세스)을 충족하는지 테스트합니다. Azure virtual machines는 일부 PaaS 옵션처럼 OS를 추상화하지 않으며, OS에 대한 완전한 제어를 제공하고 전체 .NET Framework를 지원합니다. 그러나 regional redundancy를 위해서는 application entry point와 traffic distribution layer도 regional outage를 견딜 수 있어야 합니다.
정답인 이유:
제안된 솔루션은 목표를 완전히 충족하지 않습니다. Azure Application Gateway는 regional service입니다. 두 개의 virtual machines를 서로 다른 두 Azure regions에 배포하더라도, 한 region에 있는 단일 Application Gateway는 single point of failure가 됩니다. 해당 region에 장애가 발생하면 사용자는 application에 도달할 수 없으므로, 이 설계는 end-to-end regional failover를 제공하지 않습니다.
주요 특징:
Azure VMs는 전체 .NET Framework workloads를 지원하며, 관리자가 operating system에 로그인하여 custom application dependencies를 설치할 수 있도록 합니다. 두 region에 VMs를 배포하면 workload redundancy를 지원할 수 있지만, 이는 traffic routing도 region-resilient하게 구성된 경우에만 가능합니다. 이를 달성하려면 일반적으로 Azure Front Door 또는 Azure Traffic Manager와 같은 global load-balancing service를 사용하며, 그 뒤에 regional Application Gateways 또는 load balancers를 배치합니다.
흔한 오해:
흔한 실수 중 하나는 compute resources를 두 region에 배치하면 자동으로 regional high availability가 제공된다고 가정하는 것입니다. 실제로는 ingress layer를 포함한 모든 중요 계층도 region 간에 redundant해야 합니다. 또 다른 오해는 Application Gateway를 global service로 취급하는 것입니다. 이는 regional service이며, 자체적으로 cross-region failover를 제공할 수 없습니다.
시험 팁:
AZ-305에서는 각 요구 사항을 개별적으로 확인하세요: platform/runtime 지원, administrative control, 그리고 disaster recovery architecture. 문제에서 regional outage를 견뎌야 한다고 요구하면, 단일 regional load balancer가 아니라 global traffic distribution component를 찾아야 합니다. OS-level access가 필요하다면, App Service 또는 기타 managed PaaS offerings보다 virtual machines를 우선 고려하세요.
7
문제 7
Azure Kubernetes Service (AKS) cluster에서 호스팅될 microservices architecture를 설계하고 있습니다. microservices를 사용할 앱은 Azure virtual machines에서 호스팅됩니다. virtual machines와 AKS cluster는 동일한 virtual network에 상주합니다.
consumer 앱에 microservices를 노출하기 위한 솔루션을 설계해야 합니다. 솔루션은 다음 요구 사항을 충족해야 합니다:
✑ microservices에 대한 Ingress 액세스는 단일 private IP address로 제한되어야 하며 mutual TLS authentication을 사용하여 보호되어야 합니다.
✑ 들어오는 microservice 호출 수는 rate-limited되어야 합니다.
✑ 비용은 최소화되어야 합니다.
솔루션에 무엇을 포함해야 합니까?
Azure Application Gateway with WAF는 private frontend IP로 배포할 수 있으며 L7 routing 및 WAF 보호를 제공할 수 있습니다. 그러나 API management gateway는 아니며 APIM 스타일의 rate limiting/quota policies를 기본적으로 제공하지 않습니다. 또한 이 시나리오에서 mTLS/client certificate 적용도 일반적인 강점이 아닙니다. private ingress는 부분적으로 충족할 수 있지만 전체 요구 사항 집합은 충족하지 못합니다.
APIM Standard tier는 VNet injection (internal/private gateway)을 지원하지 않습니다. “service endpoint”는 APIM에 VNet 내 private IP address를 제공하는 메커니즘이 아닙니다. 이는 특정 Azure PaaS services에 대한 subnet의 액세스를 보호하는 데 사용됩니다. 따라서 Standard는 mTLS 및 rate limiting을 제공하면서 ingress를 단일 private IP로 제한해야 하는 요구 사항을 충족할 수 없습니다.
Azure Front Door는 anycast public endpoints를 가진 전역 internet-facing 진입점입니다. WAF가 있더라도 VM-to-AKS private communication을 위해 VNet 내부의 단일 private IP로 제한된 ingress를 제공할 수 없습니다. 이는 private VNet 전용 API 노출과 internal consumer에 대한 mTLS를 위한 것이 아니라 public web acceleration 및 global load balancing을 위해 설계되었습니다.
APIM Premium tier는 virtual network connectivity (VNet injection)를 지원하며 private IP를 사용하는 internal mode로 실행될 수 있으므로, 동일한 VNet의 VM consumer에 대한 “단일 private IP” ingress 요구 사항을 충족합니다. APIM policies는 client certificate authentication (mTLS) 및 rate limiting/quota 적용을 지원합니다. Premium은 비용이 높지만, 제시된 옵션 중 명시된 모든 요구 사항을 충족하는 유일한 선택지입니다.
문제 분석
핵심 개념:
이 문제는 동일한 VNet의 VM 기반 consumer에 AKS에서 호스팅되는 microservices를 비공개로 안전하게 노출하면서, ingress 계층에서 mutual TLS (mTLS)와 rate limiting을 적용하고 비용도 고려하는 방법을 묻습니다. 핵심은 private하게 도달 가능하고(단일 private IP) rate limiting 및 client-certificate authentication과 같은 API 수준 정책을 적용할 수 있는 ingress/gateway를 선택하는 것입니다.
정답인 이유:
virtual network connection이 있는 Azure API Management (APIM) Premium tier가 가장 적절합니다. VNet에 배포되거나(또는 연결되어) private endpoint를 제공할 수 있으며(internal VNet mode를 통한 단일 private IP), client certificate authentication (mTLS) 및 rate limiting/throttling 모두에 대한 정책을 지원하기 때문입니다. internal VNet mode의 APIM을 사용하면 동일한 VNet의 consumer VM이 private IP를 통해서만 APIM을 호출할 수 있어 “단일 private IP” ingress 제한 요구 사항을 충족합니다. 그런 다음 APIM은 public endpoint를 노출하지 않고 AKS 서비스(일반적으로 internal load balancer service, private ingress controller 또는 private DNS를 통해)에 라우팅할 수 있습니다.
주요 기능/구성 포인트:
- Private ingress: APIM Premium은 VNet injection (internal mode)을 지원하므로 gateway는 VNet의 private IP를 통해서만 도달할 수 있습니다.
- mTLS: APIM이 client certificates를 요구하고 이를 검증하도록(certificate authentication) 구성하며, 선택적으로 업로드된 CA certificates에 대해 검증할 수 있습니다.
- Rate limiting: APIM policies(예: rate-limit 및 quota)를 사용하여 subscription/key별, IP별 또는 API별로 호출을 제한할 수 있습니다.
- 비용 최소화 관련 뉘앙스: Premium은 비싸지만, 제시된 옵션 중 모든 요구 사항을 동시에 충족하는 유일한 선택지입니다(private IP + mTLS + rate limiting). 시험 관점에서는 “요구 사항을 충족해야 한다”가 “비용 최소화”보다 우선합니다.
흔한 오해:
- Application Gateway/WAF는 private ingress 때문에 자주 선택되지만, APIM 스타일의 rate limiting policies를 제공하지 않으며 mTLS 적용도 이 시나리오에서의 주요 API governance 기능은 아닙니다.
- Front Door는 전역 public 진입 서비스이며 VNet 전용 액세스를 위한 단일 private IP를 제공할 수 없습니다.
- APIM Standard는 VNet injection을 지원하지 않습니다. service endpoints는 APIM을 요구된 방식으로 private하게 도달 가능하게 만들지 않습니다.
시험 팁:
“rate limit”와 “mTLS/client cert auth”가 함께 보이면 APIM policies를 떠올리십시오. 여기에 “단일 private IP”와 “동일한 VNet”이 함께 보이면 일반적으로 APIM Premium (VNet injection/internal mode) 또는 다른 private API gateway 패턴이 필요합니다. 항상 어떤 tier가 VNet connectivity를 지원하는지, 어떤 서비스가 본질적으로 public인지(예: Front Door) 확인하십시오.
8
문제 8
(2개 선택)
50,000개의 IoT devices를 포함하는 Azure IoT Hub solution을 계획하고 있습니다.
각 device는 temperature, device ID, time data를 포함한 데이터를 stream합니다. 매초 약 50,000개의 records가 기록됩니다. 데이터는 near real time으로 시각화됩니다.
데이터를 저장하고 query하기 위한 service를 추천해야 합니다.
어떤 두 가지 services를 추천할 수 있습니까? 각 정답은 완전한 solution을 제시합니다.
참고: 각 정답 선택에는 1점이 부여됩니다.
Azure Table Storage는 대용량에 적합한 저비용 key/attribute store이지만, query 기능이 제한적이며 50,000 writes/sec에서의 time-series analytics 또는 near-real-time visualization을 위해 특별히 설계되지 않았습니다. 신중한 partition/row key 설계를 통해 단순 lookups에는 사용할 수 있지만, time windows에 대한 dashboards 및 aggregations는 더 어렵고 일반적으로 추가 analytics services가 필요합니다.
Azure Event Grid는 discrete events를 handlers(Functions, Logic Apps, webhooks)로 전달하는 데 사용되는 event routing 및 notification service(pub/sub)입니다. query를 위한 data를 저장하지 않으며 time-series database도 아닙니다. IoT architecture에서 Event Grid는 events에 반응하는 데 도움이 될 수 있지만, visualization을 위해 telemetry를 저장하고 query해야 한다는 요구 사항은 충족하지 못합니다.
Azure Cosmos DB for NoSQL은 low-latency reads/writes와 elastic throughput(RU/s 또는 autoscale)을 제공하는 fully managed, horizontally scalable database입니다. 적절히 partitioning되면(대개 deviceId 기준) 매우 높은 event volumes를 ingest할 수 있으며 dashboards를 위한 최근 telemetry query를 지원합니다. TTL, global distribution, multi-region replication과 같은 기능은 높은 ingest IoT telemetry의 저장 및 query에 매우 적합합니다.
Azure Time Series Insights는 IoT time-series data를 위해 특별히 설계되었습니다: 빠른 탐색, time-window queries, 그리고 near-real-time visualization. IoT Hub/Event Hubs와 ingestion을 위해 통합되며 devices, hierarchies, measures(예: temperature)를 위한 model을 제공합니다. custom analytics UI를 구축하지 않고도 telemetry를 빠르게 시각화하는 데 일반적으로 사용되므로, streaming IoT data를 query하고 시각화하기 위한 완전한 solution입니다.
문제 분석
핵심 개념:
이 문제는 높은 ingest IoT telemetry(초당 50,000 events)와 near-real-time visualization을 위한 data store 및 query/analytics service를 선택하는지를 평가합니다. 핵심은 매우 높은 write throughput, low-latency queries, 그리고 time-series 패턴을 처리할 수 있는 services를 선택하는 것입니다.
정답이 맞는 이유:
Azure Cosmos DB for NoSQL(C)은 대규모 ingestion rate와 low-latency reads/writes를 위해 설계된 globally distributed, horizontally scalable database입니다. 적절한 partitioning(예: partition key를 deviceId로 설정하고, 필요 시 hot partitions를 피하기 위해 synthetic key 사용)을 통해 Cosmos DB는 매우 높은 RU/s를 유지할 수 있으며 최근 데이터를 query하는 real-time dashboards를 지원할 수 있습니다. 또한 telemetry에서 흔히 필요한 자동 data aging을 위한 TTL도 지원합니다.
Azure Time Series Insights(D)는 IoT time-series 탐색과 near-real-time visualization을 위해 특별히 설계되었습니다. time-series modeling, time windows에 대한 빠른 ad-hoc queries, 그리고 기본 제공 visualization 환경을 제공합니다. IoT Hub/Event Hubs와 ingestion을 위해 통합되며, temperature/device/time telemetry와 정확히 같은 시나리오를 위해 설계되었습니다.
주요 기능 및 best practices:
- Cosmos DB: writes를 고르게 분산하기 위해 적절한 partition key를 선택합니다. 50k writes/sec에 맞춰 RU/s(또는 autoscale)를 provision합니다. retention을 위해 TTL을 사용합니다. resiliency와 latency를 위해 필요한 경우 multi-region writes를 고려합니다. 이는 Azure Well-Architected Framework의 performance efficiency 및 reliability pillars와 일치합니다.
- Time Series Insights: interactive analytics 및 visualization에 사용합니다. hierarchies(device/site)와 measures(temperature)를 model링합니다. tier 및 retention 요구 사항에 따라 warm/cold retention을 구성합니다.
일반적인 오해:
- Azure Table Storage(A)는 저렴하고 scalable하지만, 이 규모에서 복잡한 near-real-time analytical queries에 최적화되어 있지 않으며 query 패턴이 제한적입니다(주로 key 기반). telemetry를 저장할 수는 있지만, Cosmos DB/TSI와 비교했을 때 “near real-time visualization을 위한 저장 및 query”에 대한 완전한 solution은 아닙니다.
- Event Grid(B)는 event routing service이지 database나 query engine이 아닙니다. events에 반응하도록 도와주지만 telemetry를 저장/query하지는 않습니다.
시험 팁:
높은 속도의 IoT telemetry와 near-real-time dashboards가 나오면 “time-series”와 “interactive exploration” 단서(Time Series Insights), 그리고 “massive ingestion + low-latency queries + global scale” 단서(Cosmos DB)를 찾으세요. 또한 routing services(Event Grid)는 storage가 아니며, 단순 key-value stores(Table Storage)는 대규모 real-time analytics 요구 사항에 종종 부족하다는 점도 기억하세요.
9
문제 9
Azure에서 third-party scheduler를 사용할 High Performance Computing (HPC) cluster를 프로비저닝할 계획입니다.
HPC cluster node를 프로비저닝하고 관리하기 위한 솔루션을 권장해야 합니다.
권장 사항에 무엇을 포함해야 합니까?
Azure Automation은 script 실행, task scheduling, configuration management 적용을 위한 범용 automation 플랫폼입니다. VM deployment 또는 deployment 후 configuration의 일부를 자동화할 수는 있지만, 기본적인 HPC cluster orchestration이나 third-party scheduler에 대한 내장 인식을 제공하지 않습니다. 또한 cluster template, scheduler 통합 autoscaling, HPC 중심 node lifecycle management와 같은 특화된 기능도 부족합니다. 따라서 Azure HPC cluster를 프로비저닝하고 관리하기 위한 최적의 서비스는 아닙니다.
Azure CycleCloud는 Azure에서 HPC 및 대규모 compute cluster를 배포, 구성, 관리하도록 특별히 설계되었습니다. Slurm, PBS Pro, Grid Engine, HTCondor와 같은 일반적인 third-party scheduler와의 통합을 지원하며, 이는 문제의 요구 사항과 정확히 일치합니다. CycleCloud는 node provisioning, cluster configuration, lifecycle operation을 자동화할 수 있으며 scheduler 수요에 따른 autoscaling도 지원합니다. 따라서 반복 가능하고 운영 효율적인 방식으로 HPC cluster node를 프로비저닝하고 관리하는 데 가장 적합한 서비스입니다.
Azure Purview는 현재 Microsoft Purview의 일부로, data governance, cataloging, classification, compliance에 중점을 둡니다. 그 목적은 조직이 여러 환경에서 data asset을 검색하고 관리하도록 돕는 것이며, compute infrastructure를 배포하거나 운영하는 것이 아닙니다. HPC node provisioning, scheduler integration, cluster resource scaling과는 관련이 없습니다. 따라서 문제에서 설명한 시나리오와는 무관합니다.
Azure Lighthouse는 특히 service provider 또는 여러 Azure tenant를 관리하는 enterprise를 위해 cross-tenant management 및 delegated administration을 목적으로 설계되었습니다. governance, monitoring, operational access를 중앙 집중화하는 데 도움이 되지만, HPC cluster를 배포하거나 관리하지는 않습니다. Lighthouse에는 scheduler integration, compute node provisioning, HPC autoscaling을 위한 내장 기능이 없습니다. 따라서 HPC cluster node를 프로비저닝하고 관리해야 한다는 요구 사항을 충족하지 못합니다.
문제 분석
핵심 개념:
이 문제는 Azure에서 High Performance Computing (HPC) cluster를 프로비저닝하고 관리하는 데 사용되는 Azure 서비스를 테스트하며, 특히 third-party scheduler와 통합하는 경우를 다룹니다(예: Slurm, PBS Pro, Grid Engine, LSF, HTCondor). 초점은 cluster lifecycle management, 즉 head/login node, compute node 배포, autoscaling, 그리고 scheduler 기반 elasticity 통합에 있습니다.
정답인 이유:
Azure CycleCloud는 Azure에서 HPC 및 big compute cluster를 배포, 관리, 최적화하도록 특별히 설계되었으며, third-party scheduler를 사용하는 cluster도 포함합니다. CycleCloud는 node를 프로비저닝하고, networking을 구성하고, storage를 연결하고, scheduler를 통합하여 job 수요에 따라 compute node를 scale out/in할 수 있도록 하는 template("cluster projects")와 orchestration을 제공합니다. 이는 third-party scheduler를 사용하여 "HPC cluster node를 프로비저닝하고 관리"해야 한다는 요구 사항과 직접적으로 일치합니다.
주요 기능 / 모범 사례:
CycleCloud는 반복 가능한 배포(infrastructure-as-code와 유사한 패턴), scheduler integration, elastic scaling policy를 지원합니다. 또한 heterogeneous node type(CPU/GPU, 다양한 VM SKU), placement 고려 사항(proximity placement group, 해당되는 경우 availability zone), 그리고 일반적인 HPC storage pattern(Azure NetApp Files, VM의 NFS, region에 따라 Lustre 제공)을 관리할 수 있습니다. Azure Well-Architected Framework 관점에서 CycleCloud는 Operational Excellence(표준화된 배포, automation, lifecycle management)와 Performance Efficiency(workload 수요에 맞춘 elastic scale)를 향상시킵니다.
일반적인 오해:
Azure Automation은 script를 실행하고 구성을 관리할 수 있지만, 범용 automation 서비스이며 기본적으로 HPC scheduler를 인식하는 cluster orchestration, template 또는 job 기반 autoscaling을 제공하지 않습니다. Purview는 data governance용이지 compute provisioning용이 아닙니다. Lighthouse는 cross-tenant management용이지 HPC cluster deployment용이 아닙니다.
시험 팁:
AZ-305에서 "HPC cluster"와 "third-party scheduler"가 함께 나오면 Azure CycleCloud(또는 Microsoft-managed scheduling의 경우 Azure Batch)를 떠올리십시오. 문제가 custom scheduler와 cluster lifecycle management를 강조하면 CycleCloud가 대표적인 Azure 서비스입니다. third-party scheduler 없이 managed job scheduling을 강조하면 일반적으로 Azure Batch가 정답입니다(여기에는 선택지로 없음).
10
문제 10
(2개 선택)
Azure 구독이 있습니다.
온-프레미스 네트워크에는 Server1이라는 파일 서버가 있습니다. Server1에는 드물게 액세스되는 5 ׀¢׀’의 회사 파일이 저장되어 있습니다.
이 파일을 Azure Storage로 복사할 계획입니다.
다음 요구 사항을 충족하는 파일용 스토리지 솔루션을 구현해야 합니다.
✑ 파일은 요청된 후 24시간 이내에 사용할 수 있어야 합니다.
✑ 스토리지 비용을 최소화해야 합니다.
이 목표를 달성하는 가능한 스토리지 솔루션 두 가지는 무엇입니까? 각 정답은 완전한 솔루션을 나타냅니다.
참고: 각 정답 선택에는 1점이 부여됩니다.
정답입니다. Blob Storage account는 Archive를 포함한 blob access tier를 지원합니다. 각 blob을 Archive로 설정하면 드물게 액세스되는 데이터의 스토리지 비용을 최소화할 수 있습니다. 요청 시 blob은 rehydrate되어야 하며(일반적으로 몇 시간, 최대 약 15시간), 이는 “24시간 이내” 요구 사항을 충족합니다. 기본 tier가 Cool인 것은 괜찮으며, 가장 낮은 steady-state 비용을 결정하는 것은 blob에 명시적으로 설정한 Archive tier입니다.
오답입니다. general-purpose v1(GPv1) storage account는 레거시 account 유형이며 GPv2/Blob account와 같은 유연한 blob tiering 및 가격 모델을 제공하지 않습니다. blob을 저장할 수 있더라도 이 옵션은 Archive tier 사용을 지정하지 않으므로, 검색 지연이 허용되는 드물게 액세스되는 데이터에 대해 요구되는 수준으로 스토리지 비용을 최소화하지 못합니다.
오답입니다. 이 옵션은 GPv2 account에서 Azure Files(file share)를 사용합니다. Azure Files는 SMB/NFS 의미 체계가 필요할 때 적합하지만, Archive tier에 해당하는 기능(offline 스토리지와 rehydration)을 제공하지 않습니다. Cool file share tier는 비용을 줄일 수 있지만, 드물게 액세스되는 데이터에 대해 Blob Archive만큼 줄일 수는 없으므로 Archive와 비교했을 때 “스토리지 비용 최소화” 의도를 충족하지 못합니다.
정답입니다. GPv2 account는 blob container와 blob access tier를 지원합니다. account 기본 tier가 Hot이더라도 각 blob을 명시적으로 Archive로 설정하면 가장 낮은 스토리지 비용을 달성할 수 있습니다. Archive에서 Hot/Cool로의 rehydration은 일반적으로 몇 시간 내(최대 약 15시간)에 완료되므로, 파일이 요청된 후 24시간 이내에 사용 가능해야 한다는 요구 사항을 충족합니다.
오답입니다. file share를 사용하는 GPv1은 드물게 액세스되는 데이터의 비용 최소화를 위한 유효하거나 최적의 설계가 아닙니다. Azure Files는 Archive tier를 제공하지 않으며, GPv1은 최신 비용 최적화 및 tiering 기능이 더 적은 레거시입니다. 또한 이 옵션은 rehydration을 통한 24시간 검색 모델을 다루지 않으며, 저비용 offline 스토리지보다는 online file share 액세스를 의미합니다.
문제 분석
핵심 개념:
이 문제는 드물게 액세스되는 데이터에 대한 Azure Storage tiering 선택, 특히 Blob Storage access tier(Hot/Cool/Archive)와 검색 시간 간의 tradeoff를 테스트합니다. 핵심 요구 사항은 “요청된 후 24시간 이내에 사용 가능”하면서 스토리지 비용을 최소화하는 것입니다.
정답이 맞는 이유:
Azure Blob Storage Archive tier는 장기 보관과 가장 낮은 스토리지 비용을 위해 설계되었습니다. Archive의 데이터는 offline 상태이며 읽기 전에 Hot 또는 Cool로 rehydrate되어야 합니다. 표준 rehydration은 일반적으로 몇 시간 내에 완료되며 최대 15시간까지 걸리는 것으로 문서화되어 있어 “24시간 이내” 요구 사항을 충족합니다. 따라서 파일을 blob으로 Archive tier에 저장하는 모든 솔루션은 가용성 요구 사항을 충족하면서 지속적인 스토리지 비용을 최소화합니다.
A와 D는 모두 파일을 blob container에 복사한 다음 blob을 Archive tier로 설정합니다. 차이점은 account의 기본 access tier(Cool vs Hot)이지만, 기본 tier는 주로 새 blob에 기본적으로 적용되는 tier와 일부 과금 동작에 영향을 줍니다. blob을 명시적으로 Archive로 설정하면 기본 tier는 비용 최소화의 결정 요소가 아닙니다. 두 경우 모두 steady-state 스토리지 비용은 Archive에 의해 최소화됩니다.
주요 기능 / 모범 사례:
- Blob Storage(또는 GPv2)와 lifecycle management를 사용하여 마지막 액세스 시간을 기준으로 데이터를 Hot/Cool에서 Archive로 자동 이동합니다.
- 비용 모델을 이해합니다: Archive는 가장 낮은 스토리지 비용을 제공하지만 더 높은 액세스/rehydration 비용과 지연 시간이 있습니다.
- 워크로드가 rehydration 지연과 잠재적인 조기 삭제 요금(Archive에는 최소 보존 기간이 있음)을 허용하는지 확인합니다.
일반적인 오해:
- Archive 없이 Cool tier만 선택하면 비용은 줄어들지만, 드물게 액세스되는 데이터에 대해서는 Archive만큼 줄어들지 않습니다.
- Azure Files(file share)는 “Archive” tier를 제공하지 않습니다. account 유형과 region에 따라 Hot/Cool/Transaction Optimized/Premium을 제공하므로, 가장 저렴한 offline 스토리지 모델을 구현할 수 없습니다.
- GPv1 account는 레거시이며 GPv2/Blob account만큼 유연하게 최신 tiering 기능을 지원하지 않습니다.
시험 팁:
“드물게 액세스됨” + “몇 시간 기다릴 수 있음” + “스토리지 비용 최소화”를 보면 Blob Archive를 떠올리십시오. 요구 사항이 “즉시 액세스”라면 대신 Hot/Cool을 선택합니다. 요구 사항이 “SMB/NFS file share”라면 Azure Files를 고려하되, Archive의 가장 저렴한 offline 스토리지 동작과는 일치하지 않는다는 점에 유의하십시오.
