CloudPass LogoCloud Pass
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
Certifications
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
Microsoft AZ-104
Microsoft AZ-104

Practice Test #1

50개 문제와 100분 시간 제한으로 실제 시험을 시뮬레이션하세요. AI 검증 답안과 상세 해설로 학습하세요.

50문제100분700/1000합격 점수
기출 문제 보기

AI 기반

3중 AI 검증 답안 및 해설

모든 답안은 3개의 최고 AI 모델로 교차 검증하여 최고의 정확도를 보장합니다. 선택지별 상세 해설과 심층 문제 분석을 제공합니다.

GPT Pro
Claude Opus
Gemini Pro
선택지별 상세 해설
심층 문제 분석
3개 모델 합의 정확도

기출 문제

1
문제 1

D:\Folder1이라는 이름의 폴더가 포함된 온-프레미스 서버가 있습니다. Azure Storage 계정 contosodata에 있는 public 컨테이너로 D:\Folder1의 내용을 복사해야 합니다. 어떤 명령을 실행해야 합니까?

이는 컨테이너 엔드포인트에 대한 URL일 뿐 명령이 아닙니다. contosodata storage account의 컨테이너에 대한 URL 형식은 올바르지만, 이것만으로는 어떤 작업도 수행하지 않습니다. 실제로는 이 URL을 AzCopy 같은 도구의 대상 매개변수로 사용하거나(종종 SAS token을 추가), SDK/CLI 작업에서 사용합니다.

`azcopy sync`는 소스와 대상이 일치하도록 동기화하는 데 사용되며, 단순 복사 요구 사항과는 다릅니다. 또한 `--snapshot`은 로컬 폴더를 컨테이너로 업로드하는 데 적절한 플래그가 아닙니다. snapshot은 blob에 적용됩니다. 폴더 내용을 Blob Storage로 복사하려면 `azcopy copy ... --recursive`가 기대되는 명령입니다.

이것이 올바른 명령입니다. `azcopy copy`는 로컬 폴더에서 Azure Blob 컨테이너로 업로드하는 것을 지원합니다. `--recursive` 플래그는 D:\Folder1 아래의 모든 파일과 하위 디렉터리를 포함하는 데 필요합니다. 이는 AZ-104에서 흔히 기대하는 내용과 일치합니다. 즉, 온-프레미스에서 Azure Storage로의 대량 전송에는 AzCopy를 사용하고, 디렉터리에는 재귀 복사를 사용합니다.

`az storage blob copy start-batch`는 Azure CLI 명령으로, blob/컨테이너 간(일반적으로 소스와 대상이 Azure에 있고 URL로 참조됨) 서버 측 복사 작업을 시작하기 위한 것입니다. D:\Folder1 같은 로컬 Windows 경로의 콘텐츠를 Blob Storage로 직접 업로드하도록 설계되지 않았습니다. 로컬에서 blob로 업로드할 때는 AzCopy가 적절한 도구입니다.

문제 분석

핵심 개념: 이 문제는 온-프레미스 파일 시스템에서 Azure Storage 계정의 blob 컨테이너로 데이터를 업로드하기 위해 올바른 도구와 구문을 사용하는 방법을 평가합니다. AZ-104에서는 Azure Blob Storage로의 고성능 데이터 전송을 위해 AzCopy를 사용하는 접근이 기대됩니다. 정답이 맞는 이유: 로컬 폴더(D:\Folder1)의 내용을 storage account contosodata의 blob 컨테이너(public)로 복사하려면, AzCopy v10 명령 `azcopy copy`를 대상 컨테이너 URL 및 `--recursive` 플래그와 함께 사용합니다. `--recursive`는 디렉터리를 순회하여 모든 파일과 하위 폴더를 업로드하는 데 필요합니다. 옵션 C의 명령은 로컬 소스 경로와 blob 컨테이너 대상 URL을 올바르게 지정하고 있으며, 디렉터리를 복사할 때의 핵심 요구 사항인 `--recursive`를 포함합니다. 주요 기능 / 모범 사례: AzCopy는 처리량에 최적화되어 있고 병렬 처리를 지원하며, Blob Storage로 대량 업로드를 수행할 때 권장되는 도구입니다. 실제 배포에서는 일반적으로 Azure AD(`azcopy login`) 또는 대상 URL에 SAS token을 추가하는 방식(자동화에서 흔함)으로 인증합니다. Azure Well-Architected Framework 관점(Performance Efficiency 및 Reliability)에서 AzCopy는 복원력이 있고 재시작 가능하며 대규모 전송을 위해 설계되었기 때문에 임시적인 방법보다 선호됩니다. 흔한 오해: 많은 응시자가 “copy”와 “sync”를 혼동합니다. `azcopy sync`는 소스와 대상을 동일하게 미러링하기 위한 것이며, 플래그에 따라 대상 파일을 삭제할 수도 있습니다. 요구 사항이 단순히 “내용을 복사”하는 것일 때는 가장 단순하거나 안전한 선택이 아닙니다. 또 다른 함정은 Azure CLI의 blob copy 명령을 사용하는 것인데, 이는 일반적으로 blob/URL 간의 서버 측 복사를 수행하며 로컬 디스크에서 업로드하는 용도가 아닙니다. 시험 팁: 소스가 온-프레미스/로컬이고 대상이 Blob Storage이면 AzCopy를 떠올리세요. 소스가 폴더라면 `--recursive`를 찾으세요. `az storage blob copy start-batch`가 보이면, 이는 보통 기존 blob을 복사하는 용도이지 로컬 파일을 업로드하는 용도가 아님을 기억하세요. 또한 단순한 컨테이너 URL만으로는 명령이 아니며, 명시적으로 묻지 않는 한 인증(AAD/SAS)은 전제됩니다.

2
문제 2

5,000개의 사용자 계정을 포함하는 Azure Active Directory (Azure AD) 테넌트가 있습니다. AdminUser1이라는 새 사용자 계정을 만듭니다. AdminUser1에 User administrator 관리 역할을 할당해야 합니다. 사용자 계정 속성에서 무엇을 해야 합니까?

오답입니다. Licenses 블레이드에서 라이선스를 할당하면 서비스에 대한 액세스가 활성화되고(예: Entra ID P1/P2 기능) 기능이 잠금 해제될 수 있지만, Azure AD 관리 권한을 부여하지는 않습니다. 관리 권한은 제품 라이선스만으로가 아니라 directory role 할당(또는 PIM의 eligibility/activation)으로 제어됩니다.

정답입니다. 사용자 계정 속성에서 Directory role(종종 Assigned roles로 표시됨) 블레이드는 해당 사용자에 대한 Azure AD directory role 할당을 추가하거나 수정하는 위치입니다. 여기에서 User administrator를 선택하면 테넌트에서 사용자 및 그룹 관리를 위한 기본 제공 관리 권한이 AdminUser1에 부여됩니다.

오답입니다. 사용자를 그룹에 초대하거나 추가하는 것만으로는 Azure AD 관리 역할이 자동으로 할당되지 않습니다. 그룹 멤버십은 해당 그룹이 role-assignable group으로 특별히 구성되고 그 그룹에 User administrator 역할이 할당된 경우에만 관리 권한을 부여합니다(설명된 것과는 다른 워크플로).

문제 분석

핵심 개념: 이 문제는 ID 관리를 위한 Azure AD (Microsoft Entra ID) 역할 기반 액세스 제어를 테스트합니다. Azure AD의 관리 권한은 디렉터리 역할(예: User administrator 같은 Entra 기본 제공 역할)을 통해 부여되며, 라이선스나 그룹 초대(역할 할당 가능 그룹을 사용하는 경우는 다른 워크플로)로 부여되지 않습니다. 정답이 맞는 이유: Azure portal에서 사용자 계정 속성에서 AdminUser1에 User administrator 역할을 할당하려면, 해당 사용자의 Directory role(또는 Assigned roles) 블레이드에서 디렉터리 역할 할당을 추가/수정합니다. 이렇게 하면 AdminUser1에 테넌트 전반에서 User administrator 역할과 연결된 권한이 직접 부여됩니다(사용하는 경우 범위가 지정된 administrative units의 적용을 받을 수 있음). 사용자가 5,000명인 테넌트 규모는 방법을 바꾸지 않으며, 역할 할당은 여전히 디렉터리 역할을 통해 수행됩니다. 주요 기능 / 모범 사례: - Azure AD 역할은 최소 권한의 관리 액세스를 제공합니다. User administrator는 사용자 및 그룹을 관리할 수 있지만 Global administrator보다 권한이 낮습니다. - Azure Well-Architected Framework 보안 원칙(최소 권한, 업무 분리, just-in-time 액세스)을 따르세요. 프로덕션에서는 Privileged Identity Management (PIM)를 사용하여 역할을 eligible로 만들고 승인/MFA를 통한 활성화를 요구하는 것을 고려하세요. - 역할 할당은 (이 문제처럼) 사용자 개체 수준에서 수행하거나, 관리를 단순화하기 위해 (활성화된 경우) role-assignable groups를 통해 수행할 수 있습니다. 일반적인 오해: - 라이선스는 제품 기능(예: M365, Entra ID P1/P2 기능)을 활성화하지만, 그 자체로 관리 권한을 부여하지는 않습니다. - 사용자를 그룹에 추가하는 것은 해당 그룹이 역할이 할당된 그룹(role-assignable group)으로 구성되어 있거나 액세스 정책에서 사용되는 경우에만 권한을 부여합니다. 단순히 “그룹에 초대”하는 것만으로는 Azure AD admin role이 할당되지 않습니다. 시험 팁: - 문제가 “관리 역할을 할당”이라고 하면, 라이선스가 아니라 “Directory role / Assigned roles”를 떠올리세요. - Azure RBAC 역할(Azure 리소스용)과 Azure AD directory roles(테넌트 ID 관리용)을 구분하세요. User administrator는 directory role입니다. - 최신 시험 시나리오에서는 PIM이 권장 접근 방식이지만, 직접 할당을 위한 portal 블레이드는 여전히 Directory role/Assigned roles입니다.

3
문제 3
(2개 선택)

Windows Server 2016 Datacenter 이미지가 사용되는 virtual machine scale set의 배포를 자동화할 계획입니다. scale set virtual machine이 프로비저닝될 때 web server 구성 요소가 설치되도록 해야 합니다. 어떤 두 가지 작업을 수행해야 합니까? 각 정답은 솔루션의 일부를 제시합니다. 참고: 각 정답 선택은 1점입니다.

정답입니다. Web Server(IIS) 역할/기능(예: Install-WindowsFeature Web-Server)을 설치하는 스크립트(Windows에서는 일반적으로 PowerShell)가 필요합니다. VMSS 자동화에서는 스크립트가 인스턴스에서 액세스 가능해야 합니다(Azure Storage의 SAS URI, GitHub 등). 스크립트를 업로드/제공하는 것은 프로비저닝 시 VM을 구성하기 위해 Custom Script Extension 또는 DSC를 사용하는 데 필요한 필수 요소입니다.

오답입니다. Automation Account는 PowerShell runbook을 실행하고 구성을 관리할 수 있지만, 모든 새 VMSS 인스턴스가 프로비저닝 시점에 구성 작업을 실행하도록 보장하는 전형적인 메커니즘은 아닙니다. VMSS 인스턴스는 동적으로 스케일 아웃되므로 외부 runbook에 의존하면 타이밍/트리거 복잡성이 증가합니다. 시험 시나리오에서는 프로비저닝 시점 구성은 VMSS 모델/템플릿에 정의된 VM extension으로 처리하는 것이 가장 적합합니다.

오답입니다. Azure Policy는 표준을 강제할 수 있고 DeployIfNotExists를 사용해 extension을 배포할 수도 있지만, 주로 거버넌스/컴플라이언스 도구(감사/거부/수정)이며 ARM 템플릿에서 VMSS 프로비저닝 중 IIS를 설치하는 직접적이고 기대되는 방법은 아닙니다. 문제는 배포를 자동화하고 VM이 프로비저닝될 때 구성 요소가 설치되도록 보장하는 작업을 묻고 있으며, 템플릿의 extension이 정석적인 접근입니다.

정답입니다. VM scale set의 ARM 템플릿에서 extensionProfile은 각 인스턴스에 적용되는 VM extension을 정의합니다. 여기에 Custom Script Extension(또는 DSC extension)을 추가하면 인스턴스가 프로비저닝될 때(스케일 아웃 포함) extension이 실행되어 필요한 web server 구성 요소를 설치합니다. 이는 프로비저닝 시점 사용자 지정을 위한 VMSS 전용 핵심 구성 지점입니다.

오답입니다. Azure portal에서 새 VM scale set을 생성하는 것은 수동 배포 방식이며 배포 자동화 요구 사항을 충족하지 않습니다. portal에서 extension을 추가할 수는 있지만, 문제는 ARM 템플릿과 프로비저닝 시점 구성을 통한 자동화를 강조합니다. AZ-104에서 portal 생성은 자동화 작업으로 간주되지 않습니다.

문제 분석

핵심 개념: 이 문제는 Azure Virtual Machine Scale Set(VMSS) 인스턴스를 프로비저닝 시점에 Azure Resource Manager(ARM) 템플릿과 VM extension을 사용해 사용자 지정하는 방법을 평가합니다. Windows VMSS의 경우 배포 중에 역할/기능(예: IIS web server 구성 요소)을 설치하는 표준 접근 방식은 VMSS 모델에 정의된 Custom Script Extension(또는 DSC)을 통해 스크립트를 실행하는 것입니다. 정답이 맞는 이유: scale set의 각 VM이 프로비저닝될 때 web server 구성 요소를 설치하도록 보장하려면 (1) 구성 로직(스크립트)을 제공하고 (2) 프로비저닝 중에 자동으로 실행되도록 scale set을 구성해야 합니다. 구성 스크립트를 업로드(A)하면 IIS/Windows 기능을 설치하는 아티팩트(예: Storage account 또는 GitHub에 저장된 PowerShell 스크립트)를 제공하게 됩니다. ARM 템플릿의 extensionProfile 섹션을 수정(D)하는 것은 Custom Script Extension(Microsoft.Compute/virtualMachineScaleSets/extensions)을 VMSS에 연결하여 각 인스턴스가 첫 부팅/프로비저닝 시 스크립트를 실행하도록 하는 방법입니다. 주요 기능 / 모범 사례: - VMSS extension(Custom Script Extension 또는 DSC)을 사용하여 인스턴스 전반에 일관된 구성을 적용합니다. - 스크립트는 신뢰할 수 있는 위치(Azure Storage의 SAS 또는 신뢰할 수 있는 repo)에 저장하고 버전 관리를 합니다. - 멱등성(idempotency)을 보장합니다. 스크립트는 여러 번 실행되어도 안전해야 합니다(재이미지/업그레이드 시나리오에서 중요). - 이는 Azure Well-Architected Framework의 Operational Excellence와 일치합니다: 배포 자동화, 반복 가능한 infrastructure-as-code 사용, 구성 드리프트 감소. 흔한 오해: - Automation Account(B)는 배포 후 구성 또는 예약된 runbook에 유용하지만, 각 VMSS 인스턴스의 프로비저닝 시점 실행을 본질적으로 보장하지는 않습니다. - Azure Policy(C)는 구성을 감사/거부할 수 있고 DeployIfNotExists를 통해 일부 extension을 배포할 수도 있지만, VMSS 배포 자동화 시나리오에서 프로비저닝 중 IIS 설치에 대한 1차/기대되는 시험 정답은 아닙니다. - Azure portal에서 VMSS를 생성(E)하는 것은 수동이며 자동화된 배포 요구 사항을 충족하지 않습니다. 시험 팁: AZ-104에서 “VM이 프로비저닝될 때 소프트웨어/구성 요소가 설치되도록 보장”이라는 문구가 보이면 “VM extension + ARM/Bicep”을 떠올리세요. “extensionProfile”(VMSS) 또는 “resources -> extensions”(VM)와 스크립트/DSC 페이로드 소스(Storage/GitHub)를 찾으세요.

4
문제 4

참고: 이 질문은 동일한 시나리오를 제시하는 일련의 질문 중 하나입니다. 이 시리즈의 각 질문에는 명시된 목표를 충족할 수도 있는 고유한 솔루션이 포함되어 있습니다. 일부 질문 세트에는 정답이 두 개 이상 있을 수 있으며, 다른 세트에는 정답이 없을 수도 있습니다. 이 섹션에서 질문에 답한 후에는 해당 질문으로 돌아갈 수 없습니다. 따라서 이러한 질문은 검토 화면에 표시되지 않습니다. Computer1이라는 컴퓨터가 VNet1이라는 Azure virtual network에 point-to-site VPN 연결을 가지고 있습니다. point-to-site 연결은 self-signed certificate를 사용합니다. Azure에서 Computer2라는 컴퓨터에 VPN client configuration package를 다운로드하여 설치합니다. Computer2에서 VNet1에 대한 point-to-site VPN 연결을 설정할 수 있도록 해야 합니다. 솔루션: Azure Active Directory (Azure AD) authentication policies를 수정합니다. 이것이 목표를 충족합니까?

예가 오답인 이유는 Azure AD authentication policy는 Azure VPN gateway가 인증 방법으로 Azure AD를 사용하도록 구성된 경우에만 중요하기 때문입니다. 이 시나리오에서는 연결이 self-signed certificate를 사용하므로 certificate trust와 certificate 설치가 결정적인 요소입니다. VPN client package만으로는 Computer2에 client certificate가 필요하다는 점을 대체할 수 없습니다. 올바른 certificate가 없으면 Azure AD policy 변경과 관계없이 Computer2는 VNet1에 인증할 수 없습니다.

아니요가 정답인 이유는 P2S 연결이 self-signed certificate를 사용하고 있으므로 인증이 Azure AD policy가 아니라 certificate에 의존하기 때문입니다. Computer2에는 Azure VPN gateway에 구성된 trusted root certificate로 체인되는 유효한 client certificate가 private key를 포함하여 설치되어 있어야 합니다. Azure AD authentication policy를 수정해도 Computer2에 필요한 certificate material이 제공되지는 않습니다. 따라서 제안된 작업으로는 Computer2에서 VPN 연결을 사용할 수 없습니다.

문제 분석

핵심 개념: 이 문제는 Azure point-to-site (P2S) VPN 인증 방법과 certificate authentication이 사용될 때 다른 client device에서 연결하기 위해 무엇이 필요한지를 테스트합니다. self-signed certificate로 구성된 P2S VPN에서는 client computer에 Azure VPN gateway에 업로드된 trusted root certificate로 체인되는 client certificate가 설치되어 있어야 합니다. 정답인 이유: 제안된 솔루션은 목표를 충족하지 못합니다. self-signed certificate를 사용하는 certificate-based authentication을 사용하는 P2S VPN 연결에는 Azure Active Directory authentication policy를 수정해도 영향이 없기 때문입니다. Computer2에서 연결하려면 Computer1에서 client certificate(private key 포함)를 export하거나, 동일한 trusted root에서 새 client certificate를 생성하여 Computer2에 설치해야 합니다. 주요 특징: Azure P2S는 certificate authentication, Azure AD authentication, RADIUS를 포함한 여러 인증 방법을 지원합니다. certificate authentication의 경우 Azure는 device가 제시한 client certificate가 VPN gateway에 구성된 trusted root certificate로 체인되는지 검증합니다. 필요한 client certificate도 device에 존재하지 않는 한 VPN client package만 설치하는 것으로는 충분하지 않습니다. 흔한 오해: 흔한 실수는 VPN client configuration package에 연결에 필요한 모든 것이 포함되어 있다고 가정하는 것입니다. certificate-based P2S 구성에서는 package가 connection setting을 제공하지만, client certificate와 private key는 여전히 client machine에 존재해야 합니다. 또 다른 오해는 gateway가 Azure AD authentication을 사용하지 않는 경우에도 Azure AD policy 변경이 도움이 될 수 있다고 생각하는 것입니다. 시험 팁: AZ-104에서는 항상 먼저 P2S authentication type을 식별하세요. 시나리오에 self-signed certificate 또는 root/client certificate가 언급되면 Azure AD policy가 아니라 certificate distribution과 certificate chain trust를 떠올려야 합니다. 문제에서 Azure AD authentication이 명시적으로 언급된 경우에만 Azure AD setting이 관련될 수 있습니다.

5
문제 5

다음 전시와 같이 구성될 Azure virtual machine인 VM1을 생성할 계획입니다.

VM1에 대해 계획된 disk 구성은 다음 전시에 표시되어 있습니다.

VM1을 Availability Zone에서 생성할 수 있도록 해야 합니다. 어떤 두 가지 설정을 수정해야 합니까? 각 정답은 해결 방법의 일부를 제시합니다. 참고: 각 정답 선택은 1점입니다.

파트 1:

아래 이미지에서 올바른 답(들)을 선택하세요.

question-image

제시된 화면은 VM이 Use managed disks가 No로 설정되고 storage account가 선택된 상태임을 보여주며, 이는 unmanaged disks를 사용하고 있음을 의미합니다. Availability Zones에 배포되는 Azure VM은 반드시 managed disks를 사용해야 하므로, 이 설정은 변경되어야 합니다. 필요한 다른 변경 사항은 Basics 탭에 있으며, 여기서 Availability options를 No infrastructure redundancy required에서 Availability zone으로 변경해야 합니다. Disks 탭에 표시된 다른 설정들(예: OS disk type)은 그 자체만으로는 zonal deployment를 방해하지 않습니다.

파트 2:

배포된 리소스와 비용을 관리할 구독을 선택합니다. 리소스 그룹을 폴더처럼 사용하여 모든 리소스를 구성하고 관리합니다. 구독 ______

구독 선택은 청구, RBAC, 그리고 정책 범위를 위한 관리 컨테이너일 뿐입니다. 문제에서 구독 필드는 단일 옵션인 “MyDev-Test Subscription”으로 제시됩니다. 다른 구독 옵션이 제공되지 않았으므로, 이것이 올바른 선택입니다. 이 설정은 Availability Zone 기능에 직접적인 영향을 주지 않습니다. 대신 리소스가 생성되는 위치와 적용되는 할당량, 정책, 권한에 영향을 줍니다. 실제 배포에서는 대상 region/zone에서 구독에 충분한 vCPU quota가 있는지, 그리고 Azure Policy가 zonal 배포를 제한하지 않는지도 확인합니다. 하지만 이 하위 문제에서는 사용 가능한 유일한 구독 옵션이 정답입니다.

파트 3:

Resource group ______

Resource group은 수명 주기 관리(배포, 업데이트, 삭제)와 그룹 수준에서 RBAC를 적용하기 위한 논리적 컨테이너입니다. 문제에서 사용 가능한 옵션으로 “RG1”을 제공하므로, 이것이 올바른 선택입니다. Resource group은 Availability Zone 지원 여부를 결정하지 않으며, region-agnostic 컨테이너입니다(그 안의 리소스는 region을 가집니다). 하지만 운영 우수성(Azure Well-Architected Framework) 관점에서 워크로드(예: VM1 및 해당 NIC, disks, public IP 등)를 위한 전용 RG를 사용하면 관리, tagging, 비용 분석이 단순해집니다. 제공된 옵션이 RG1뿐이므로 이를 선택합니다.

파트 4:

가상 머신 이름 ______

VM 이름은 컴퓨팅 리소스를 식별하는 식별자이며 Azure portal, ARM resource ID, 그리고 (구성에 따라) DNS 명명 규칙에서 자주 사용됩니다. 문제에서 VM1이라는 이름의 VM을 생성할 계획이라고 했고, 제공된 옵션이 “VM1”이므로 정답입니다. 이 설정은 Availability Zone 적격성에 영향을 주지 않습니다. 다만 Windows 배포에서는 OS 내부의 컴퓨터 이름에 추가 제약(길이/문자)이 있을 수 있으며, Azure가 이를 자동 생성하거나 VM 이름과 일치시키도록 정렬할 수 있습니다. 시험에서는 제공된 VM 이름 옵션을 선택하면 됩니다.

파트 5:

Region ______

Region은 VM과 해당 VM에 종속된 리소스가 배포되는 위치와 Availability Zones를 사용할 수 있는지 여부를 결정합니다. 제공된 옵션은 “(US) West US 2”이며, 이는 Availability Zones를 지원하는 Region입니다. Region 선택은 존(Zone) 기반 배포에 매우 중요합니다. 모든 Region에 AZ가 있는 것은 아니기 때문입니다. 존을 지원하지 않는 Region을 선택하면, 디스크 설정과 관계없이 Availability Zone을 선택할 수 없습니다. 이 문제에서는 West US 2가 AZ 배포에 적합합니다. 또한 VM size와 일부 기능은 Region에 따라 달라질 수 있으므로, 선택한 VM size가 West US 2 내에서 선택한 Zone에서 사용 가능한지 반드시 확인해야 합니다.

파트 6:

가용성 옵션 ______

Availability Zone에 VM1을 생성하려면 Availability options 설정을 No infrastructure redundancy required에서 Availability zone으로 변경해야 합니다. No infrastructure redundancy required로 그대로 두면 zonal placement가 없는 일반적인 regional VM이 생성됩니다. 이는 managed disks를 활성화하는 것과 함께 필요한 두 가지 수정 사항 중 하나입니다. availability set 또는 no redundancy와 같은 옵션은 특정 zone에 배포해야 한다는 요구 사항을 충족하지 않습니다.

파트 7:

이미지 ______

이미지는 VM을 생성하는 데 사용되는 OS 템플릿을 정의합니다. 제공된 옵션은 “Windows Server 2016 Datacenter”이며, 이는 프롬프트의 구성 선택과 일치하고 사용 가능한 유일한 옵션입니다. 일반적으로 OS 이미지는 VM을 Availability Zone에 배포할 수 있는지 여부에 영향을 주지 않습니다. Zone 지원은 주로 region 기능, 해당 zone에서의 VM size 가용성, 그리고 storage/disk 구성(managed disks)에 의해 결정됩니다. 따라서 이 하위 질문에 대해 Windows Server 2016 Datacenter를 선택하는 것은 올바르지만, zonal deployment를 활성화하기 위해 변경할 설정 중 하나는 아닙니다.

파트 8:

Azure Spot instance ______

Azure Spot instances는 Azure가 용량을 다시 필요로 할 때 회수(evict)될 수 있는 할인된 compute capacity입니다. Spot은 Availability Zone에 배포하는 데 필수 요구 사항이 아니며, 언제든지 회수가 발생할 수 있으므로 Spot을 활성화하면 reliability가 저하될 수 있습니다. 목표가 VM1이 Availability Zone에서 생성될 수 있도록 보장하는 것(신뢰성 중심 요구 사항)이므로, 비용 최적화와 중단 허용(interruption-tolerant) workload에 대해 명시적으로 요구되지 않는 한 Spot을 비활성화하는 것이 더 안전하고 일반적인 시험 답입니다. 따라서 “아니요”를 선택합니다. 이는 Azure Well-Architected reliability 가이드라인(명시적으로 회수 및 대체 처리를 하지 않는 한 high availability가 필요한 workload에는 Spot을 사용하지 말 것)과도 일치합니다.

이동 중에도 모든 문제를 풀고 싶으신가요?

Cloud Pass를 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.

6
문제 6

Azure 구독이 있습니다. Azure virtual machine 100개가 있습니다. 더 저렴한 offering으로 service tier를 변경할 수 있는 활용도가 낮은 virtual machine을 빠르게 식별해야 합니다. 어떤 blade를 사용해야 합니까?

Azure Monitor는 Azure 리소스 전반의 telemetry(metrics, logs, alerts)를 수집, 분석, 조치하는 데 사용됩니다. 낮은 CPU 또는 낮은 network usage를 찾기 위해 dashboards와 alerts를 만들 수는 있지만, Monitor는 활용도가 낮은 VMs에 대해 prescriptive한 cost right-sizing 권장 사항을 본질적으로 제공하지는 않습니다. 많은 VMs 전반에서 자동화된 cost-optimization 가이드보다는 관찰 및 alerting에 더 적합합니다.

Azure Advisor가 정답인 이유는 cost optimization을 위한 기본 제공 권장 사항을 제공하며, 여기에는 활용도가 낮은 virtual machines 식별이 포함되기 때문입니다. VM usage patterns를 평가하고 더 작은 SKU로 resize하거나 적절한 경우 shutdown하기에 적합한 machine을 표시합니다. 이는 많은 수의 VMs 전반에서 optimization 기회를 검토하기 위한 가장 빠른 portal blade입니다. 단순히 telemetry를 표시하는 것이 아니라 usage data를 실행 가능한 가이드로 전환하도록 특별히 설계되었습니다.

Metrics(일반적으로 Azure Monitor Metrics를 통해 액세스)는 CPU percentage, disk, network와 같은 time-series performance data를 보여줍니다. VM의 활용도가 낮은지 판단하는 데 도움이 될 수 있지만, 수동 분석 또는 custom dashboards/queries가 필요하며 더 저렴한 VM size를 자동으로 권장하지는 않습니다. prescriptive guidance와 함께 빠르게 식별하려면 Advisor가 더 적절합니다.

Customer Insights(Dynamics 365 Customer Insights / Microsoft Customer Insights)는 customer profiles와 analytics를 통합하기 위한 customer data platform입니다. Azure VM utilization을 모니터링하거나 compute tiers에 대한 cost-saving 변경을 권장하는 역할은 없습니다. 이 옵션은 Azure infrastructure management 및 cost optimization과 관련이 없습니다.

문제 분석

핵심 개념: 이 문제는 compute에 대한 Azure Advisor의 cost optimization 권장 사항을 테스트합니다. Azure Advisor는 리소스 구성과 사용 telemetry(VM CPU/network utilization 패턴 포함)를 분석하고, 활용도가 낮은 virtual machines의 resizing 또는 shutdown과 같은 실행 가능한 권장 사항을 제공합니다. 정답인 이유: "quickly identify underutilized virtual machines"를 찾아 "less expensive offering"으로 이동해야 합니다(즉, 더 작은 VM SKU/service tier로 resize). Azure Advisor는 정확히 이 시나리오를 위해 설계되었습니다. 많은 리소스(100 VMs)에 대해 중앙 집중식 권장 사항을 제공하고, "Right-size or shut down underutilized virtual machines"를 포함한 cost-saving 기회를 강조합니다. 이는 VM별로 metrics를 수동으로 확인하는 것보다 더 빠르고 확장성이 뛰어납니다. 주요 기능 및 모범 사례: Advisor 권장 사항은 Azure Well-Architected Framework pillar에 맞춘 카테고리(Cost, Security, Reliability, Operational Excellence, Performance)로 그룹화되며, 이 시나리오는 Cost Optimization에 해당합니다. Advisor는 지속적으로 낮은 utilization을 기준으로 VM right-sizing을 표시할 수 있으며, SKU resizing, workload 통합, 또는 reserved instances/savings plans 사용에 대한 가이드를 포함할 수 있습니다(문맥에 따라 다름). 또한 작업의 우선순위를 정하고 remediation을 추적하는 데도 도움이 됩니다. 일반적인 오해: - Monitor/Metrics는 utilization을 보여줄 수 있지만, fleet 전체에 걸쳐 그 데이터를 자동으로 cost optimization 작업으로 변환하지는 않습니다. queries, dashboards, thresholds를 만들고 결과를 해석해야 합니다. - "Metrics"는 Azure Monitor 내의 기능이며 일반적으로 리소스별 또는 dashboard 중심입니다. cost right-sizing 권장 사항을 위한 기본 blade는 아닙니다. - Customer Insights는 관련이 없습니다(customer data platform). 시험 팁: 문제에서 "identify underutilized resources"와 "less expensive offering/service tier"가 언급되면 Azure Advisor(Cost 권장 사항)를 떠올리세요. 작업이 "view raw performance data"라면 Azure Monitor/Metrics를 떠올리세요. fleet 전체에 대한 recommendation 기반 cost optimization에는 portal에서 Advisor가 대표적인 서비스입니다. 참고: cost 권장 사항(right-size/shut down underutilized VMs)에 대한 Azure Advisor documentation 및 Azure Well-Architected Framework Cost Optimization pillar.

7
문제 7

VM1, VM2, VM3라는 이름의 Azure virtual machine 3대를 배포할 계획입니다. 해당 virtual machine은 App1이라는 web app을 호스팅합니다. 단일 Azure datacenter를 사용할 수 없게 되더라도 최소 두 대의 virtual machine을 사용할 수 있도록 보장해야 합니다. 무엇을 배포해야 합니까?

오답입니다. VM 3대를 모두 단일 Availability Zone에 배치하면 동일한 zone/datacenter 경계를 공유합니다. 해당 datacenter(zone)를 사용할 수 없게 되면 VM 3대 모두 영향을 받아 남는 VM이 0대가 됩니다. 단일 zone에서도 fault domain을 사용할 수는 있지만, 이는 zone 전체 장애로부터 보호하지 못합니다.

틀렸습니다. Availability Set은 국지적인 하드웨어 장애와 계획된 유지 관리 이벤트의 영향을 줄이기 위해 VM을 fault domain과 update domain에 분산합니다. 그러나 Availability Zones와 같은 물리적 분리를 제공하지 않으며, 전체 datacenter/zone 손실로부터 보호하기 위한 용도가 아닙니다. 요구 사항이 구체적으로 datacenter를 사용할 수 없게 되는 상황에서도 살아남는 것이라면, Availability Set만으로는 충분하지 않습니다.

정답입니다. 각 VM을 서로 다른 Availability Zone에 배치하면 datacenter 수준의 장애 격리가 제공됩니다. 어떤 한 zone을 사용할 수 없게 되더라도 다른 두 zone에서 VM이 계속 실행되므로, 최소 두 대의 VM이 가용 상태로 유지된다는 요구 사항을 충족합니다. 이는 region 내에서 zone 수준 복원력을 확보하는 표준 접근 방식입니다.

틀렸습니다. 각 VM을 별도의 Availability Set에 배치한다고 해서 서로 다른 datacenter나 격리된 zone에 배포된다는 보장은 없습니다. Availability Sets는 zone 수준 또는 datacenter 수준 격리를 위한 것이 아니라 fault domain과 update domain 분리를 위한 구성입니다. 따라서 별도의 Availability Sets를 사용하더라도 datacenter 장애 중 최소 두 개의 VM을 계속 사용 가능하게 유지해야 한다는 요구 사항을 충족하지 못합니다.

문제 분석

핵심 개념: 이 문제는 Availability Sets가 아니라 Availability Zones를 사용하여 단일 datacenter 손실에 대비한 Azure VM 복원력을 어떻게 설계하는지 테스트합니다. Availability Zones는 하나의 region 내에서 물리적으로 분리된 위치이므로, VM을 여러 zone에 분산하면 datacenter 수준 장애로부터 보호하면서 나머지 zonal VM은 계속 온라인 상태를 유지할 수 있습니다. 정답인 이유: 각 VM을 서로 다른 Availability Zone에 배포하면 하나의 datacenter/zone을 사용할 수 없게 되더라도 해당 zone의 VM만 영향을 받습니다. 나머지 두 VM은 다른 zone에서 계속 실행되므로, 최소 두 개의 virtual machine이 계속 사용 가능해야 한다는 요구 사항을 충족합니다. 이것이 region 내에서 zone 수준 고가용성을 위한 Azure 고유의 설계입니다. 주요 기능 / 구성: Availability Zones는 각각 별도의 전원, 냉각, 네트워킹을 갖추고 있어 서로 격리됩니다. App1과 같은 애플리케이션의 경우 일반적으로 zonal VM을 Standard Load Balancer 또는 zone-redundant Application Gateway와 함께 사용하여 살아남은 VM으로 트래픽이 계속 전달되도록 합니다. 또한 Availability Zones를 지원하고 선택한 zone에서 사용할 수 있는 VM size를 제공하는 region을 선택해야 합니다. 흔한 오해: 흔한 실수는 Availability Sets가 전체 datacenter 장애로부터 보호한다고 생각하는 것입니다. Availability Sets는 host 장애, rack 수준 문제, 계획된 유지 관리의 영향을 줄이기 위해 VM을 fault domain과 update domain에 분산하지만, Availability Zones와 같은 datacenter 수준 격리를 제공하지는 않습니다. 또 다른 오해는 여러 VM을 하나의 zone에 배치해도 충분하다고 생각하는 것인데, zone 장애가 발생하면 여전히 그 VM 모두가 영향을 받습니다. 시험 팁: 요구 사항에 datacenter를 사용할 수 없게 되는 상황이 언급되면 Availability Zones를 떠올리세요. 반대로 계획된 유지 관리나 국지적인 하드웨어 장애로부터의 보호가 언급되면 Availability Sets를 떠올리세요. AZ-104에서는 VM 배치만으로는 애플리케이션 가용성이 충분하지 않다는 점도 기억하세요. 일반적으로 VM 앞단에 load-balancing service가 필요합니다.

8
문제 8

HOTSPOT - Subscription1이라는 Azure 구독이 있습니다. Subscription1에는 다음 표의 리소스가 포함되어 있습니다. 이름 유형 RG1 Resource group RG2 Resource group VNet1 Virtual network VNet2 Virtual network VNet1은 RG1에 있습니다. VNet2는 RG2에 있습니다. VNet1과 VNet2 간에는 연결이 없습니다. Admin1이라는 관리자가 RG1에 VM1이라는 Azure virtual machine을 생성합니다. VM1은 Disk1이라는 디스크를 사용하고 VNet1에 연결됩니다. 그런 다음 Admin1은 VM1에 사용자 지정 애플리케이션을 설치합니다. 사용자 지정 애플리케이션을 VNet2로 이동해야 합니다. 솔루션은 관리 작업을 최소화해야 합니다. 어떤 두 가지 작업을 수행해야 합니까? 답하려면 답안 영역에서 적절한 옵션을 선택하십시오. 참고: 각 정답 선택은 1점입니다. 핫 영역:

파트 1:

첫 번째 작업: ______

정답: C (VM1 삭제). 기존 Azure VM의 virtual network는 변경할 수 없으며, NIC를 다른 VNet으로 이동할 수도 없습니다. VM을 삭제하면 managed disk(Disk1)는 유지하면서 VM 리소스(compute object)만 제거할 수 있고, Disk1에는 OS와 설치된 custom application이 포함되어 있습니다. 이는 동일한 workload를 최소한의 재구성으로 VNet2에 재배포할 수 있게 해주는 핵심 단계입니다. 다른 선택지가 틀린 이유: - A (RG2에 network interface 생성): NIC만 생성해도 애플리케이션이 이동하지 않으며, VM1은 여전히 VNet2로 전환할 수 없습니다. - B (network interface 분리): NIC 분리/연결로는 VNet을 변경할 수 없고, 또한 일반적인 single-NIC VM에서는 primary NIC 분리가 지원되지 않습니다. - D (network interface를 RG2로 이동): NIC를 resource group 간에 이동해도 해당 NIC의 VNet/subnet 연결은 변경되지 않으며 VNet2에 대한 연결성을 제공하지 않습니다.

파트 2:

두 번째 작업: ______

정답: C (새 virtual machine을 생성합니다). VM1을 삭제한 후(Disk1은 유지), VNet2에 연결된 새 VM을 생성합니다. VM 생성 중 Disk1을 OS disk로(또는 사용 방식에 따라 data disk로) 연결하면, custom application을 재설치하지 않고도 함께 가져올 수 있습니다. 이는 application을 VNet2에 배치해야 한다는 요구 사항을 충족하며 administrative effort를 최소화합니다. 다른 선택지가 틀린 이유: - A (network interface를 연결): NIC를 연결하는 것만으로는 충분하지 않습니다. VNet2에 있는 VM이 필요하며, 기존 VM에 VNet2 NIC를 단순히 연결해서 VNet을 변경할 수는 없습니다. - B (RG2에서 network interface를 생성): NIC는 구성 요소일 뿐이며, 그 자체로 application을 배포하지는 않습니다. - D (VM1을 RG2로 이동): VM을 다른 resource group으로 이동해도 VNet은 변경되지 않습니다. VM1은 여전히 VNet1에 있으며 VNet2로의 connectivity가 없습니다.

9
문제 9

HOTSPOT - 다음 표에 표시된 App Service plan이 있습니다.

diagram

다음 표에 표시된 Azure web app을 만들 계획입니다. 이름 | Runtime stack | Location WebApp1 | .NET Core 3.0 | West US WebApp2 | ASP.NET 4.7 | West US web app에 사용할 수 있는 App Service plan을 식별해야 합니다. 무엇을 식별해야 합니까? 답하려면, 답안 영역에서 적절한 옵션을 선택하십시오. 참고: 각 정답 선택은 1점입니다. Hot Area:

파트 1:

WebApp1: ______

WebApp1은 .NET Core 3.0을 사용하며 West US에 배포되어야 합니다. .NET Core 앱은 Windows App Service와 Linux App Service 모두에서 지원됩니다. 따라서 해당 OS 중 하나를 사용하면서 West US에 있는 플랜이 적합합니다. ASP1은 West US의 Windows App Service plan이며 Windows는 .NET Core를 지원하므로 적합합니다. ASP3은 West US의 Linux App Service plan이며 Linux는 .NET Core를 지원하므로 적합합니다. ASP2는 Windows( .NET Core 지원)임에도 Central US에 위치해 있으므로 적합하지 않습니다. App Service plan은 다른 region에 있는 앱을 호스팅할 수 없습니다. 따라서 정답은 ASP1 및 ASP3만입니다.

파트 2:

WebApp2: ______

WebApp2는 ASP.NET 4.7을 사용하며, 이는 클래식 .NET Framework runtime입니다. Azure App Service에서 .NET Framework(ASP.NET 4.x)는 Windows 기반 App Service plan에서만 지원되며, Linux App Service plan에서는 지원되지 않습니다. 또한 web app에 필요한 location은 West US이므로, plan도 West US에 있어야 합니다. ASP1은 West US의 Windows이므로 ASP.NET 4.7을 지원하고 region도 일치합니다. ASP3은 West US의 Linux이지만, Linux App Service는 ASP.NET 4.7(.NET Framework)을 지원하지 않으므로 유효하지 않습니다. ASP2는 Windows이지만 Central US에 있으므로 region 요구 사항을 충족하지 못합니다. 따라서 WebApp2에는 ASP1만 사용할 수 있습니다.

10
문제 10

참고: 이 질문은 동일한 시나리오를 제시하는 일련의 질문 중 일부입니다. 이 시리즈의 각 질문에는 제시된 목표를 충족할 수도 있는 고유한 솔루션이 포함되어 있습니다. 일부 질문 세트에는 정답이 둘 이상 있을 수 있으며, 다른 세트에는 정답이 없을 수도 있습니다. 이 섹션의 질문에 답한 후에는 해당 질문으로 돌아갈 수 없습니다. 따라서 이러한 질문은 검토 화면에 표시되지 않습니다. 다음 표에 표시된 리소스를 포함하는 Azure 구독이 있습니다.

diagram

VM1은 VNET1에 연결됩니다. VM1을 VNET2에 연결해야 합니다. 솔루션: VM1을 RG2로 이동한 다음, VM1에 새 네트워크 인터페이스를 추가합니다. 이것이 목표를 충족하나요?

예는 오답입니다. 이 솔루션은 resource group을 변경하면 VM의 regional placement도 변경된다고 가정하지만, Azure에서는 그렇지 않습니다. Resource group은 관리용 컨테이너일 뿐이며 resource가 배포되는 위치에는 영향을 주지 않습니다. VM1에 연결되는 NIC는 여전히 West US에 있어야 하지만, VNET2는 East Asia에 있습니다. 이러한 region 불일치 때문에 제안된 방법으로는 VM을 VNET2에 직접 연결할 수 없습니다.

아니요가 정답인 이유는 VM1을 RG2로 이동해도 VM의 region이 West US에서 East Asia로 변경되지 않기 때문입니다. Azure virtual machine은 VM과 동일한 region의 virtual network에 연결된 network interface만 연결할 수 있습니다. VNET2는 East Asia에 있으므로, NIC를 추가하는 방식으로 VM1을 여기에 직접 연결할 수 없습니다. 따라서 제안된 단계는 명시된 목표를 달성하지 못합니다.

문제 분석

핵심 개념: 이 문제는 지역 간 Azure virtual machine 네트워킹 제약을 테스트합니다. virtual machine은 VM과 동일한 Azure region의 virtual network에 연결된 network interface만 연결할 수 있습니다. VM을 resource group 간에 이동해도 해당 region은 변경되지 않습니다. 정답인 이유: 제안된 솔루션은 목표를 충족하지 못합니다. VM1은 West US에 있고 VNET2는 East Asia에 있기 때문입니다. VM1을 RG1에서 RG2로 이동하더라도, resource group을 변경해도 resource의 region은 변경되지 않으므로 VM은 여전히 West US에 있습니다. 따라서 VNET2에 연결된 NIC를 VM1에 추가할 수 없습니다. 주요 기능 및 모범 사례: - Azure VM은 VM과 동일한 region의 NIC만 사용할 수 있습니다. - VNet은 regional resource이며, NIC는 동일한 region의 VNet 내 subnet에 속해야 합니다. - resource를 다른 resource group으로 이동해도 다른 region으로 이동되지는 않습니다. - region 간에 workload를 연결하려면 VNet peering, VPN Gateway를 사용하거나, 대상 region에 VM을 다시 만들거나 마이그레이션해야 합니다. 일반적인 오해: 흔한 실수는 VM을 다른 resource group으로 이동하면 location도 함께 변경된다고 가정하는 것입니다. Resource group은 논리적 컨테이너일 뿐이며 서로 다른 region의 resource를 포함할 수 있지만, resource group 이동 후에도 resource의 region은 변경되지 않습니다. 또 다른 오해는 보조 NIC를 추가하면 regional networking 제한을 우회할 수 있다고 생각하는 것이지만, NIC 역시 region에 종속됩니다. 시험 팁: AZ-104에서는 region이 resource group이 아니라 resource의 속성이라는 점을 기억하세요. VM이 VNet에 직접 연결되어야 한다면, VM과 해당 NIC는 모두 그 VNet과 동일한 region에 있어야 합니다. region 간 networking 문제가 나오면 단순히 resource group을 이동하는 것보다 peering 또는 migration을 떠올리세요.

다른 모의고사

Practice Test #2

50 문제·100분·합격 700/1000

Practice Test #3

50 문제·100분·합격 700/1000

Practice Test #4

50 문제·100분·합격 700/1000

Practice Test #5

50 문제·100분·합격 700/1000

Practice Test #6

50 문제·100분·합격 700/1000

Practice Test #7

50 문제·100분·합격 700/1000

Practice Test #8

50 문제·100분·합격 700/1000

Practice Test #9

50 문제·100분·합격 700/1000
← 모든 Microsoft AZ-104 문제 보기

지금 학습 시작하기

Cloud Pass를 다운로드하고 모든 Microsoft AZ-104 기출 문제를 풀어보세요.

Get it on Google PlayDownload on the App Store
Cloud PassCloud Pass

IT 자격증 문제풀이 앱

Get it on Google PlayDownload on the App Store

자격증

AWSGCPMicrosoftCiscoCompTIADatabricks

법률

FAQ개인정보 처리방침서비스 약관

회사

문의하기계정 삭제

© Copyright 2026 Cloud Pass, All rights reserved.

이동 중에도 모든 문제를 풀고 싶으신가요?

앱 받기

Cloud Pass를 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.