Practice Test #2

정답: D (storage1, storage2, 및 storage3). Recovery Services vault에 대한 diagnostic setting(AzureBackupReports category)을 구성할 때, 로그를 Storage account로 보관(archive)할 수 있습니다. 이 대상(destination)의 경우 storage account가 vault와 동일한 region에 있을 필요는 없으며, 쓰기 권한이 있는 유효한 Storage account(동일 tenant 및 적절한 RBAC)면 됩니다. 표에서 storage1은 East US, storage2는 West US, storage3는 West Europe에 있습니다. 모두 유효한 Storage account이므로 diagnostic destination으로 선택할 수 있습니다. 다른 선택지가 틀린 이유: - A, B, C는 region 또는 resource group을 기준으로 단일 storage account로만 제한한다고 잘못 가정합니다. Resource group location은 diagnostic settings를 제한하지 않으며, 이 컨텍스트에서 platform logs를 보관하기 위한 cross-region storage destination이 지원됩니다.

정답: C (Analytics3만). Vault1에서 진단 설정을 통해 Azure Backup Reports를 사용하려면, Log Analytics workspace는 Recovery Services vault와 동일한 region에 있어야 합니다. Vault1은 West Europe에 있습니다. 사용 가능한 workspace 중 Analytics1은 East US, Analytics2는 West US, Analytics3는 West Europe에 있습니다. 따라서 동일 region 요구 사항을 충족하는 것은 Analytics3뿐입니다. 다른 선택지가 틀린 이유: - A (Analytics1만) 및 B (Analytics2만)는 vault와 다른 region에 있으므로 이 log category에 사용할 수 없습니다. - D (세 개 모두)는 이 특정 vault 진단 log category에 대해 cross-region Log Analytics ingestion이 지원되지 않기 때문에 틀립니다. 지원되는 구성 및 데이터 상주(data residency) 제약을 충족하려면 workspace가 vault의 region과 일치해야 합니다.

정답은 Hyper-V Integration Services에서 Guest services를 활성화하는 것에 해당하는 옵션입니다. 제시된 이미지는 Integration Services 설정에 초점을 맞추고 있으며, 표시된 설정 중 비활성화되어 있는 관련 항목은 Guest services뿐입니다. disk format을 VHD로 변경하는 것은 이 이미지에서 나타나지 않으므로, 현재 설명은 이미지에 제시되지 않은 정보를 기반으로 하고 있습니다. time synchronization, heartbeat, backup과 같은 다른 Integration Services 항목들은 VM disk를 Azure VM template로 사용하도록 준비하는 것과는 관련이 없습니다.

이 항목은 Azure 동작에 대한 실제 시험 선택지를 나타내는 것이 아니라, 이미지가 제공된다는 것을 나타내는 placeholder일 뿐입니다. 이 하위 문제에 대해서는 기술적인 판단이 필요하지 않으므로, self-assessment gate로 설명해서는 안 됩니다. 의미 있는 기술적 답변은 exhibit에 표시된 VMSS autoscale settings를 기반으로 하는 후속 hotspot statements에 있습니다.

Scale1은 4개의 instance로 시작합니다. 제시된 내용은 평균 CPU가 5분 동안 80%를 초과하면 instance 수를 2 증가시키는 scale-out rule을 보여줍니다. CPU가 6분 동안 85%이므로 해당 rule 조건이 충족되어 scale set은 6개의 instance로 증가합니다. 구성된 cooldown은 즉시 반복적인 scale action을 방지하므로, 이 시나리오에서는 한 번의 증가만 적용됩니다. 결과는 최소 2와 최대 20 범위 내에 있으므로, 6개의 virtual machine이 정답입니다.

Scale1은 4개의 instance로 시작합니다. 처음 6분 동안 CPU가 25%이므로, CPU가 30% threshold보다 낮아 scale-in rule 조건을 충족합니다. 따라서 scale set은 4만큼 감소를 시도하지만, autoscale은 구성된 minimum 아래로 내려갈 수 없으므로 2개의 instance까지만 scale in됩니다. 그 이후에는 cooldown period가 적용되며, 다음 6분 동안 CPU가 50%인 구간은 어느 autoscale threshold도 충족하지 않습니다. 50%는 80%를 초과하지도 않고 30% 미만도 아니므로 추가 scaling은 발생하지 않으며, 결과적으로 Scale1은 2개의 virtual machine 상태로 유지됩니다.

정답: D (Zone-redundant storage - ZRS). ZRS는 동일한 region 내의 3개 Azure Availability Zones에 걸쳐 데이터를 동기식으로 복제합니다. zone은 전력, 냉각, 네트워킹이 독립적인 별도의 datacenter이므로, ZRS는 하나의 datacenter/zone에 장애가 발생하더라도 storage account의 가용성을 유지하도록 설계되었습니다. 이는 “region 내 단일 data center가 실패하더라도 계속 사용 가능”이라는 요구사항과 “동기식으로 복제”라는 요구사항에 직접 부합합니다. 다른 선택지가 틀린 이유: - B (LRS)는 동기식이지만 단일 datacenter 내에서만 복제본을 유지하므로, datacenter 장애 시 account를 사용할 수 없게 됩니다. - A (GRS)와 C (RA-GRS)는 secondary region으로 비동기식 복제를 수행하므로 동기식 복제 요구사항을 충족하지 못합니다. 이들은 주로 primary region 내 단일 datacenter 장애가 아니라 region 수준의 재해 복구를 위한 것입니다.

정답: C (StorageV2 - general purpose v2). StorageV2는 거의 모든 신규 Azure Storage 배포에 권장되는 계정 유형입니다. 가장 광범위한 storage 서비스와 기능(최신 blob 기능, lifecycle management, 다양한 보안 및 성능 기능 포함)을 지원하며, 대부분의 실제 아키텍처와 시험 시나리오에서 기본 선택입니다. 문제에서 레거시 유형이 필요하다고 명시적으로 요구하지 않는 한 StorageV2를 선택하는 것이 일반적입니다. 다른 선택지가 틀린 이유: - A (Blob storage)는 blob에 초점을 둔 특화/레거시 계정 유형이며, 신규 계정에 대한 기본 권장 사항은 일반적으로 아닙니다. - B (Storage - general purpose v1)는 레거시이며 일부 최신 기능과 최적화가 부족합니다. AZ-104에서 GPv1을 강제하는 제약이 없다면, 모범 사례 옵션으로 StorageV2를 선택합니다.

Endpoint1은 cloud endpoint입니다. Azure File Sync 용어에서 cloud endpoint는 Azure Storage account에서 호스팅되는 Azure Files share(SMB/NFS file share)입니다. 각 sync group에는 정확히 하나의 cloud endpoint가 있으며, 이는 권한 있는 cloud copy이자 동기화를 위한 허브 역할을 합니다. 이는 중요한데, 어떤 server endpoint에서든 변경 사항이 먼저 cloud endpoint로 업로드된 다음 다른 server endpoints로 배포되기 때문입니다. Endpoint1이 Azure에서 직접(예: Azure portal, Storage Explorer, 또는 Azure file share에 대한 SMB 액세스) “파일을 추가”하는 위치라면, 이는 cloud endpoint에 쓰는 것입니다. 왜 “아니요”가 아닌가: server endpoint는 항상 Azure File Sync agent가 설치된 등록된 Windows Server의 경로이며, Azure file share가 아닙니다. 따라서 Endpoint1이 cloud endpoint라는 것은 Azure File Sync 아키텍처와 일치합니다.

Endpoint2는 server endpoint입니다. Server endpoint는 Storage Sync Service에 등록되고 sync group에 조인된 Windows Server(또는 Windows Server VM) 상의 특정 폴더 경로를 나타냅니다. Server endpoint는 multi-master sync에 참여하므로, cloud endpoint로 변경 사항을 업로드할 수도 있고 cloud endpoint로부터 변경 사항을 다운로드할 수도 있습니다. 이 분류는 이후의 file-availability 질문에 중요합니다. File2가 Endpoint2(server endpoint)에서 생성되면, Azure File Sync는 agent를 통해 변경을 감지하고, 해당 파일을 cloud endpoint(Endpoint1)로 업로드한 다음, 동일한 sync group 내의 다른 server endpoint로 동기화합니다. “아니요”가 아닌 이유: Endpoint2가 server endpoint가 아니라면 cloud endpoint여야 하는데(하지만 sync group당 cloud endpoint는 하나뿐이며 Endpoint1이 이미 그 역할을 수행함), 또는 sync group에 속하지 않아야 합니다. 이는 Endpoint2가 sync group의 endpoint라고 명시한 시나리오와 모순됩니다.

Endpoint3도 server endpoint입니다. 문제에서 Endpoint3에 대해 cloud tiering이 활성화되어 있다고 명시하고 있으며, cloud tiering은 cloud endpoint가 아니라 server endpoint에서 구성되는 기능입니다. Tiering을 사용하면 Endpoint3는 자주 액세스되는 파일을 로컬에 캐시로 유지하면서, 더 오래된(덜 사용되는) 파일은 Azure Files로 “tiering”하고 로컬에는 placeholder를 남깁니다. 이는 시험에서 중요한 단서입니다. 어떤 endpoint에서 tiering이 활성화되어 있다면, 해당 endpoint는 Azure File Sync agent가 로컬 스토리지와 recall 동작을 관리하는 server endpoint여야 합니다. 왜 “아니요”가 아닌가: Azure File Sync에서 Azure Files(= cloud endpoint)에는 endpoint별 cloud tiering 설정이 없습니다. Tiering은 Windows Servers의 로컬 디스크 용량을 관리하기 위한 기능이므로, Endpoint3는 server endpoint여야 합니다.

File1은 Endpoint1(클라우드 endpoint/Azure file share)에 추가됩니다. Azure File Sync는 sync group 내의 모든 server endpoint(Endpoint2 및 Endpoint3)로 클라우드 endpoint의 변경 사항을 동기화합니다. 따라서 24시간 이내에 File1은 Endpoint1, Endpoint2 및 Endpoint3에서 사용할 수 있습니다. Endpoint3에서 cloud tiering이 활성화되어 있어도 해당 파일을 사용할 수 없게 되지는 않습니다. tiering이 활성화된 경우, tiering policy가 전체 내용을 로컬에 유지하지 않도록 결정하면 Endpoint3는 File1을 tiered file(placeholder)로 저장할 수 있습니다. 그러나 파일은 여전히 namespace에 표시되며, 액세스 시 recall될 수 있습니다. 다른 옵션이 틀린 이유: - Endpoint1만: cloud-to-server sync를 무시합니다. - Endpoint3만: 파일이 클라우드 endpoint에서 시작되며 모든 서버로 동기화되어야 한다는 점을 무시합니다. - Endpoint2 및 Endpoint3만: 파일이 클라우드 endpoint에도 그대로 남아 있다는 점을 무시합니다.

파일2는 Endpoint2(서버 endpoint)에 추가됩니다. Azure File Sync는 서버 endpoint 전반에서 multi-master입니다. Endpoint2에서 생성된 변경 사항은 cloud endpoint(Endpoint1)로 업로드된 다음 다른 서버 endpoint(Endpoint3)로 동기화됩니다. 따라서 24시간 이내에 파일2는 Endpoint1, Endpoint2 및 Endpoint3에서 사용할 수 있습니다. 다시 말해, Endpoint3의 cloud tiering은 로컬 스토리지 동작에만 영향을 줍니다. 파일2는 Endpoint3에 표시되며, 사용 가능한 공간과 tiering 정책에 따라 완전히 캐시되거나 tiered(placeholder)일 수 있지만, 여전히 해당 endpoint의 namespace에서 사용 가능한 것으로 간주됩니다. 다른 옵션이 틀린 이유: - Endpoint1만: 원본 서버 endpoint가 파일을 유지하고 다른 서버가 동기화된다는 점을 무시합니다. - Endpoint3만: cloud로의 업로드와 Endpoint2에서의 유지(보관)를 무시합니다. - Endpoint2 및 Endpoint3만: cloud endpoint가 업로드된 데이터를 항상 수신하여 중앙 복사본이 된다는 점을 무시합니다.