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

Practice Test #4

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

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

AI 기반

3중 AI 검증 답안 및 해설

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

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

기출 문제

1
문제 1
(2개 선택)

정책 기반 virtual network gateway인 GW1과 virtual network인 VNet1이 포함된 Azure subscription이 있습니다. 온-프레미스 컴퓨터에서 VNet1으로 point-to-site 연결을 구성할 수 있도록 해야 합니다. 어떤 두 가지 작업을 수행해야 합니까? 각 정답은 해결 방법의 일부를 제시합니다. 참고: 각 정답 선택은 1점입니다.

오답입니다. Service endpoint는 VNet에서 Storage 또는 SQL Database와 같은 Azure PaaS 서비스로 최적화된 private access를 제공하는 데 사용됩니다. 이는 VPN 연결을 생성하지 않으며, on-premises 컴퓨터에서 point-to-site access를 활성화하는 데 아무 역할도 하지 않습니다. 이 선택지는 virtual network gateway 유형이나 P2S 요구 사항과 관련이 없습니다.

오답입니다. virtual network gateway를 reset하면 일시적인 운영 문제를 복구하는 데 도움이 될 수 있지만, gateway 아키텍처나 지원 기능을 변경하지는 않습니다. reset으로 policy-based gateway를 route-based gateway로 변환할 수 없으므로 P2S를 가능하게 만들 수 없습니다. 여기서의 문제는 일시적인 장애가 아니라 설계상의 제한입니다.

정답입니다. Azure의 point-to-site VPN은 route-based virtual network gateway를 필요로 합니다. 이는 P2S가 policy-based gateway가 제공하지 않는 dynamic routing 기능에 의존하기 때문입니다. 따라서 route-based gateway를 생성하는 것은 P2S 구성을 적용하기 전에 반드시 필요한 단계입니다. 이것은 개별 on-premises 디바이스에서 Azure virtual network로의 client VPN 연결에 대해 지원되는 gateway 유형입니다.

오답입니다. GW1에 connection을 추가하는 것은 policy-based gateway에서 point-to-site를 활성화하기 위해 필요한 단계가 아닙니다. P2S는 지원되는 route-based virtual network gateway에서 client address pool 및 authentication 설정을 사용해 직접 구성되며, 지원되지 않는 gateway에 단순히 connection object를 추가하는 방식이 아닙니다. GW1은 애초에 P2S를 전혀 지원할 수 없으므로, 이 작업으로는 문제를 해결할 수 없습니다.

정답입니다. GW1은 현재 policy-based이며, Azure는 기존 policy-based gateway를 route-based로 직접 변경하는 것을 허용하지 않습니다. 필요한 route-based gateway를 배포하려면 먼저 지원되지 않는 기존 gateway를 삭제해야 합니다. 이는 Azure networking에서 표준적인 교체 시나리오이며, P2S 활성화를 위한 전제 조건으로 자주 출제됩니다.

오답입니다. Azure virtual network는 private IP address space를 사용하며, VNet에 public IP address space를 추가하는 것은 point-to-site VPN에 필요하지도 않고 적절하지도 않습니다. P2S에는 VNet 자체에 할당된 public address range가 아니라, VPN client address pool과 gateway 배포에 연결된 public IP resource가 필요합니다. 이 선택지는 Azure VNet addressing에 대한 오해를 반영합니다.

문제 분석

핵심 개념: Azure point-to-site (P2S) VPN 연결은 route-based virtual network gateway에서만 지원됩니다. policy-based gateway는 P2S에 사용할 수 없으며, Azure는 policy-based gateway를 route-based로 제자리에서 변환하는 것을 지원하지 않습니다. 정답인 이유: GW1이 policy-based이므로, P2S를 구성하기 전에 이를 삭제하고 새로운 route-based virtual network gateway로 교체해야 합니다. 주요 기능: Route-based gateway는 P2S, site-to-site, 그리고 VNet-to-VNet 시나리오를 지원하는 반면, policy-based gateway는 더 제한적이며 P2S를 지원하지 않습니다. 흔한 오해: connection object를 생성한다고 해서 지원되지 않는 gateway 유형에서 P2S가 활성화되는 것은 아니며, service endpoint 또는 VNet address 변경은 VPN gateway 기능과 관련이 없습니다. 시험 팁: 문제에서 P2S와 policy-based gateway가 함께 언급되면, 즉시 gateway를 삭제하고 route-based로 다시 생성해야 한다고 생각하세요.

2
문제 2

최근 Admin1이라는 사용자가 포함된 새 Azure 구독을 만들었습니다. Admin1은 Azure Resource Manager 템플릿을 사용하여 Azure Marketplace 리소스를 배포하려고 합니다. Admin1은 Azure PowerShell을 사용하여 템플릿을 배포하고 다음 오류 메시지를 받습니다: User failed validation to purchase resources. Error message: Legal terms have not been accepted for this item on this subscription. To accept legal terms, please go to the Azure portal (http://go.microsoft.com/fwlink/?LinkId=534873) and configure programmatic deployment for the Marketplace item or create it there for the first time.` Admin1이 Marketplace 리소스를 성공적으로 배포할 수 있도록 해야 합니다. 무엇을 해야 합니까?

Set-AzApiManagementSubscription은 Azure API Management(APIM) 내에서 API 소비자를 위한 구독을 관리합니다. 이는 Azure Marketplace 구매 또는 법적 약관 수락과 관련이 없습니다. 이 cmdlet은 Marketplace 리소스의 ARM 템플릿 배포에 영향을 주지 않으며, 오류에서 나타난 구독 수준 Marketplace 약관 요구 사항을 해결하지 못합니다.

Microsoft.Marketplace 리소스 공급자 등록은 일부 Marketplace 관련 작업에 필요할 수 있지만, 오류 메시지는 공급자 등록이 아니라 미수락된 법적 약관을 구체적으로 언급합니다. 공급자 등록이 문제라면 일반적으로 등록되지 않은 namespace/provider에 대한 오류가 표시됩니다. 공급자만 등록한다고 해서 게시자 약관이 수락되지는 않습니다.

Set-AzMarketplaceTerms는 구독에서 특정 Marketplace offer/plan에 대한 법적 약관을 수락하는 데 사용되며, 프로그래밍 방식 배포(ARM/PowerShell/CLI)를 가능하게 합니다. 이는 명시된 유효성 검사 실패를 직접 해결합니다. 일반적으로 Get-AzMarketplaceTerms로 약관을 확인한 다음 Set-AzMarketplaceTerms -Accept로 해당 구독에 대한 수락을 기록합니다.

Billing administrator 역할을 할당하면 청구, 청구서 및 일부 구매 관련 설정을 관리할 수 있는 사용자가 변경되지만, 특정 offer/plan에 대한 Marketplace 법적 약관이 자동으로 수락되지는 않습니다. 배포 실패 원인은 권한 부족이 아니라 수락 누락입니다. 청구 권한이 있더라도 약관은 명시적으로 수락해야 합니다.

문제 분석

핵심 개념: 이 문제는 프로그래밍 방식 배포(ARM/Bicep/PowerShell/CLI)에서 Azure Marketplace 이미지/법적 약관 수락을 테스트합니다. 많은 Marketplace 오퍼는 자동화를 통해 배포하기 전에 구독 단위로 게시자 법적 약관을 수락해야 합니다. 이는 컴퓨팅 또는 RBAC 문제가 아니라 거버넌스 및 배포의 사전 요구 사항입니다. 정답이 맞는 이유: 오류는 “Legal terms have not been accepted for this item on this subscription”이라고 명시하며 “configure programmatic deployment for the Marketplace item or create it there for the first time”라고 안내합니다. Azure PowerShell에서는 Marketplace 약관을 수락하는 올바른 방법이 약관을 가져온 다음(Get-AzMarketplaceTerms) Set-AzMarketplaceTerms(일반적으로 -Accept 사용)로 수락하는 것입니다. 수락이 완료되면 해당 Marketplace 오퍼를 참조하는 ARM 템플릿 배포를 성공적으로 진행할 수 있습니다. 주요 기능 / 동작 방식: Marketplace 오퍼(VM 이미지, managed applications, 일부 SaaS)는 법적 수락이 필요할 수 있습니다. 수락은 특정 publisher/offer/plan 조합에 대해 구독 수준에 저장됩니다. 자동화를 위해서는 PowerShell/CLI/REST로 약관을 프로그래밍 방식으로 수락하거나, portal에서 한 번 배포(수락 프롬프트 표시)해야 합니다. 이는 Azure Well-Architected Framework 거버넌스 원칙과도 일치합니다. 즉, 자동화된 배포 전에 사전 요구 사항과 규정 준수 요구 사항이 충족되었는지 확인해야 합니다. 흔한 오해: 흔한 실수는 문제가 리소스 공급자 등록(Microsoft.Marketplace) 누락 또는 RBAC/청구 권한 부족이라고 가정하는 것입니다. 공급자 등록이 배포를 막을 수는 있지만, 그 경우 오류 메시지는 법적 약관이 아니라 공급자 등록 문제를 나타냅니다. 또한 Billing administrator를 할당해도 법적 약관이 자동으로 수락되지는 않으며, 단지 청구를 관리할 수 있는 사용자만 변경됩니다. 시험 팁: Marketplace 배포에서 “Legal terms have not been accepted”를 보면 “Marketplace 약관 수락”(Set-AzMarketplaceTerms / az vm image terms accept)을 떠올리십시오. 또한 수락은 구독별이며 plan별이라는 점을 기억하십시오. 템플릿에서 plan을 변경하면 약관을 다시 수락해야 할 수 있습니다. 참고: Microsoft 문서의 Azure Marketplace 프로그래밍 방식 배포 및 약관 수락(Get/Set-AzMarketplaceTerms).

3
문제 3

참고: 이 질문은 동일한 시나리오를 제시하는 일련의 질문 중 일부입니다. 이 시리즈의 각 질문에는 제시된 목표를 충족할 수도 있는 고유한 솔루션이 포함되어 있습니다. 일부 질문 세트에는 정답이 둘 이상 있을 수 있으며, 다른 세트에는 정답이 없을 수도 있습니다. 이 섹션에서 질문에 답한 후에는 해당 질문으로 돌아갈 수 없습니다. 따라서 이러한 질문은 검토 화면에 표시되지 않습니다. 10개의 virtual network가 포함된 Azure subscription이 있습니다. virtual network는 각각 별도의 resource group에 호스팅되어 있습니다. 다른 관리자가 subscription에서 여러 network security group(NSG)을 만들 계획입니다. NSG가 생성될 때 virtual network 간의 TCP port 8080을 자동으로 차단하도록 해야 합니다. 솔루션: Resource providers 블레이드에서 Microsoft.ClassicNetwork provider의 등록을 취소합니다. 이것이 목표를 충족합니까?

Yes는 오답입니다. Microsoft.ClassicNetwork를 unregister하는 것은 legacy classic networking resource provider에만 영향을 주며 새로 생성되는 NSG에 security rules를 적용하지 않습니다. TCP port 8080에 대한 deny rule을 생성하지도 않고, ARM-based virtual networks 간의 트래픽을 제어하지도 않습니다. 요구 사항은 생성 시점에 NSG를 자동으로 구성하는 것이므로 governance 또는 deployment tooling이 필요합니다. 따라서 Yes라고 답하면 provider registration이 NSG 동작을 강제할 수 있다고 잘못 가정하게 됩니다.

No가 정답인 이유는 Microsoft.ClassicNetwork provider를 unregister해도 NSG를 구성하거나 그 안에 deny rules를 삽입하지 않기 때문입니다. 현재 Azure 환경의 NSG는 Microsoft.Network 아래의 ARM resources이므로 classic provider는 이 요구 사항과 관련이 없습니다. virtual networks 간의 TCP port 8080을 자동으로 차단하려면 Azure Policy 또는 automation처럼 NSG rules를 평가하거나 배포하는 메커니즘이 필요합니다. 따라서 제안된 작업은 명시된 목표를 충족하지 않습니다.

문제 분석

핵심 개념: 이 문제는 Azure VM maintenance controls와 platform maintenance에 사전에 대응하는 방법을 테스트합니다. Azure는 VM이 maintenance 대상으로 예약되었다고 알릴 수 있습니다(예: host OS updates 또는 hardware servicing). 관련 기능은 VM Maintenance/Updates 아래에 있으며, “Redeploy”(새 host로 이동) 같은 옵션과 경우에 따라 “Self-service maintenance” controls를 포함합니다. 정답인 이유: VM1 Updates blade에서 “One-time update”를 선택하는 것은 VM을 즉시 다른 host로 이동시키는 목표를 충족하지 않습니다. “One-time update”는 updates/patches 적용(guest OS updates 또는 update management actions)과 관련이 있으며 host 변경을 강제하지 않습니다. VM을 즉시 다른 host로 이동시키려면 일반적으로 VM을 Redeploy하는 작업(새 node에서 중지/deallocate 후 시작) 또는 platform maintenance events를 위해 특별히 설계된 maintenance controls를 사용해야 합니다. 따라서 제안된 솔루션은 요구 사항을 충족하지 않습니다. 주요 기능 및 모범 사례: - “Redeploy”는 VM을 새로운 Azure host로 강제로 이동시키는 일반적인 운영 작업입니다. 이 작업은 downtime을 발생시키고 새로운 host assignment를 수행하지만, disks와 configuration은 유지합니다. - 더 높은 availability를 위해 Availability Sets 또는 Availability Zones를 사용하여 platform maintenance가 instance의 일부에만 영향을 주도록 하고 application layer에서 fail over할 수 있도록 합니다. - Azure Well-Architected Framework (Reliability)는 reactive host moves에 의존하기보다 redundancy(zones/sets)를 통해 planned maintenance에 대비하도록 설계할 것을 권장합니다. 일반적인 오해: “Updates”(patching/Update Management)와 “Maintenance”(platform host maintenance)를 혼동하기 쉽습니다. 둘 다 “maintenance”와 관련이 있지만, host placement에 영향을 주는 것은 redeploy/maintenance controls뿐입니다. one-time update를 적용하면 guest OS vulnerability를 줄일 수는 있지만 기본 host는 변경되지 않습니다. 시험 팁: AZ-104에서는 다음을 기억하세요: “Redeploy” = VM을 새로운 host로 이동. “Restart”는 host 변경을 보장하지 않습니다. “Updates/One-time update”는 patching과 관련이 있으며 host migration이 아닙니다. 문제에서 명시적으로 “즉시 다른 host로 이동”이라고 하면 Redeploy를 떠올리세요(또는 예방을 묻는 경우 zone/availability design).

4
문제 4

Subscription1이라는 Azure 구독이 있으며, 여기에는 VNet1 및 VNet2라는 두 개의 Azure virtual network가 포함되어 있습니다. VNet1에는 static routing을 사용하는 VPNGW1이라는 VPN gateway가 포함되어 있습니다. 온-프레미스 네트워크와 VNet1 간에 site-to-site VPN connection이 있습니다. Windows 10을 실행하는 Client1이라는 컴퓨터에서 VNet1에 대한 point-to-site VPN connection을 구성합니다. VNet1과 VNet2 간에 virtual network peering을 구성합니다. 온-프레미스 네트워크에서 VNet2로 연결할 수 있음을 확인합니다. Client1은 VNet2에 연결할 수 없습니다. Client1을 VNet2에 연결할 수 있도록 해야 합니다. 무엇을 해야 합니까?

VPN client configuration package를 다운로드하고 다시 설치하면 point-to-site 클라이언트가 받는 route 정보가 업데이트됩니다. VNet peering이 구성된 후에도 package가 새로 고쳐지기 전까지는 클라이언트에 여전히 VNet1에 대한 route만 있을 수 있으므로, VNet2로 가는 트래픽이 VPN tunnel을 통해 전송되지 않습니다. on-premises가 이미 VNet2에 도달할 수 있으므로, Azure 측의 peering과 gateway 경로는 정상적으로 동작하고 있습니다. 남아 있는 문제는 클라이언트 측 route 집합이며, 이는 업데이트된 VPN package를 다시 설치하면 해결됩니다.

Allow gateway transit는 gateway를 포함하는 VNet에서 사용되며, peered VNet이 해당 gateway를 remote gateway로 사용할 수 있게 합니다. 이 설정은 특히 site-to-site 또는 ExpressRoute 시나리오에서 VNet 간 gateway 공유와 관련이 있지만, 이미 설치된 P2S 클라이언트의 route table을 그 자체로 업데이트하지는 않습니다. 이 문제에서는 클라이언트가 VNet1에 연결할 수 있고 peering이 이미 Azure 측 연결을 허용하고 있으므로, 문제는 gateway transit를 활성화하는 것만으로 해결되지 않습니다. 클라이언트는 여전히 VNet2가 VPN tunnel을 통해 도달되어야 한다는 것을 알기 위해 새로 고쳐진 route 정보가 필요합니다.

VNet2에서 Allow gateway transit를 선택하는 것은 올바르지 않습니다. 왜냐하면 VNet2에는 VPN gateway가 없기 때문입니다. Azure peering에서 gateway가 있는 VNet은 Allow gateway transit를 사용해 이를 노출하고, peered VNet은 Use remote gateways를 사용해 이를 소비합니다. gateway-sharing 설정이 관련이 있다고 하더라도, 이 특정 옵션은 잘못된 쪽에 적용된 것입니다. 따라서 Client1이 VNet2에 도달하지 못하는 문제를 해결하지 못합니다.

BGP는 호환되는 VPN device 및 gateway와 동적 route 교환에 사용되지만, 이 시나리오의 gateway는 static routing을 사용합니다. 더 중요한 점은, 설명된 문제는 Azure와 on-premises 간 동적 route 교환 부족이 아니라는 것입니다. 왜냐하면 on-premises는 이미 VNet2에 성공적으로 도달하고 있기 때문입니다. 실패 원인은 point-to-site 클라이언트에 peered VNet에 대한 업데이트된 도달 가능 정보가 없다는 점에만 해당합니다. 여기서 BGP를 활성화하는 것은 필요한 해결책도 아니고 직접적인 해결책도 아닙니다.

문제 분석

핵심 개념: Point-to-site VPN 클라이언트는 도달 가능한 address space에 대해 클라이언트로 푸시되는 route가 포함된 client configuration package를 사용합니다. virtual network peering과 같은 연결을 추가하거나 변경하면, 새로운 peered VNet prefix가 클라이언트에 포함되도록 P2S 클라이언트에 업데이트된 VPN package가 필요할 수 있습니다. 정답인 이유: Client1은 이미 VNet1에 연결할 수 있고, on-premises는 VNet2에 도달할 수 있으므로 peering 자체는 정상적으로 동작하고 있음을 보여줍니다. 빠진 부분은 P2S 클라이언트에 아직 VNet2에 대한 route 정보가 없다는 점이며, 따라서 VPN client package를 다시 설치하면 클라이언트 측 route가 업데이트됩니다. 핵심 기능: P2S route distribution은 client-profile 기반이고, peering은 도달 범위를 확장할 수 있으며, route 업데이트는 종종 VPN client package를 다시 생성/다운로드해야 합니다. 흔한 오해: 많은 사람들이 VNet 간 gateway 공유에 사용되는 gateway transit 설정과, topology 변경 후 P2S 클라이언트 route를 새로 고쳐야 하는 별도의 요구 사항을 혼동합니다. 시험 팁: P2S 클라이언트가 새로 peered된 address space에 도달할 수 없지만 VNet끼리는 통신할 수 있다면, 먼저 다운로드한 VPN client package를 업데이트하는 것을 생각하세요.

5
문제 5

귀사의 런던 본사에는 100대의 클라이언트 컴퓨터가 있습니다. 3년 전, Azure Active Directory (Azure AD)로 마이그레이션했습니다. 회사의 보안 정책에 따르면 모든 개인 디바이스와 회사 소유 디바이스는 Azure AD에 등록되거나 조인되어야 합니다. User1이라는 원격 사용자가 가정 네트워크에서 개인 디바이스를 Azure AD에 조인할 수 없습니다. User1이 과거에는 Azure AD에 디바이스를 조인할 수 있었음을 확인했습니다. User1이 해당 디바이스를 Azure AD에 조인할 수 있도록 해야 합니다. 어떻게 해야 합니까?

오답입니다. User administrator 역할은 사용자 개체 및 일부 사용자 설정을 관리하지만, 표준 사용자가 디바이스를 조인/등록하는 데 필요하지도 않고 이를 특별히 활성화하지도 않습니다. 디바이스 조인 문제를 해결하기 위해 관리자 역할을 부여하는 것은 최소 권한 원칙을 깨며 의도된 제어 방식이 아닙니다.

정답입니다. User1이 사용자별 디바이스 할당량에 도달했다면 Azure AD는 추가 조인/등록을 차단합니다. “Maximum number of devices per user”를 늘리면(또는 대안으로 User1의 오래되거나 사용하지 않는 디바이스 개체를 제거하면) Device settings에서 거버넌스를 중앙에서 유지하면서 문제를 해결할 수 있습니다. 이는 증상(이전에는 동작했지만 이제 특정 사용자에게서 실패)과 일치합니다.

오답입니다. Azure AD join/registration은 Microsoft Entra ID 엔드포인트로 인터넷을 통해 수행되며 Azure로의 point-to-site VPN이 필요하지 않습니다. VPN은 내부 리소스 액세스나 특정 hybrid ID 워크플로에는 관련이 있을 수 있지만, 가정에서 개인 디바이스를 Azure AD에 조인하는 전제 조건은 아닙니다.

오답입니다. “Users may join devices to Azure AD”는 광범위한 테넌트 설정(대개 All 또는 Selected)입니다. 이것이 잘못 구성되었다면 일반적으로 많은 사용자에게 영향을 주거나 과거에 User1이 디바이스를 조인하지 못했을 가능성이 큽니다. 이 시나리오는 테넌트 전체 조인 권한 문제라기보다 사용자별 제한을 시사합니다.

문제 분석

핵심 개념: 이 문제는 Azure AD (Microsoft Entra ID) 디바이스 ID 관리, 특히 누가 디바이스를 조인/등록할 수 있는지와 사용자가 조인할 수 있는 디바이스 수를 제어하는 설정을 평가합니다. Azure AD에서 사용자는 디바이스를 Azure AD join(일반적으로 회사 소유)하거나 register(BYOD를 위한 workplace join)할 수 있습니다. 관리자는 Device settings를 통해 디바이스 조인/등록을 제한할 수 있으며, 여기에는 사용자별 디바이스 할당량이 포함됩니다. 정답이 맞는 이유: User1은 과거에는 디바이스를 조인할 수 있었지만 지금은 할 수 없습니다. 흔한 원인 중 하나는 사용자가 “Maximum number of devices per user” 한도에 도달한 경우입니다. 할당량을 초과하면 회사 네트워크든 집이든 상관없이 Azure AD가 해당 사용자에 대한 추가 디바이스 조인/등록을 차단합니다. 이 한도를 늘리거나(또는 오래된 디바이스 개체를 정리) 하면 User1이 개인 디바이스를 조인할 수 있는 기능이 복구됩니다. 주요 기능/구성: Entra admin center에서: Identity > Devices > Device settings. 관련 제어 항목은 “Maximum number of devices per user”입니다. 기본값은 종종 50이지만, 조직에서는 보안/자산 통제를 위해 이를 낮추기도 합니다. 모범 사례는 적절한 한도를 설정하고 주기적으로 오래된 디바이스를 제거(또는 device cleanup rules 사용)하여 위험과 관리 오버헤드를 줄이는 것입니다. 이는 Azure Well-Architected Framework의 보안 원칙(최소 권한 및 ID/디바이스 수명주기에 대한 강력한 거버넌스 유지)과도 부합합니다. 흔한 오해: - “Users may join devices to Azure AD”는 테넌트 전체에 적용되는 게이트입니다. 이것이 비활성화되었거나 제한되어 있었다면 User1은 과거에도 디바이스를 조인하지 못했을 가능성이 높고(또는 많은 사용자가 영향을 받았을 것) 시나리오와 덜 일치합니다. - User administrator를 할당하는 것은 디바이스 조인 기능을 부여하지 않으며 최소 권한 원칙을 위반합니다. - Azure AD join/registration에는 VPN이 필요하지 않습니다. 이는 인터넷 기반의 클라우드 작업입니다. 시험 팁: 특정 사용자 한 명이 갑자기 디바이스를 조인하지 못하지만 이전에는 가능했다면, 먼저 할당량과 사용자별 제한을 떠올리십시오. 아무도 조인할 수 없다면 테넌트 전체 Device settings 또는 conditional access/디바이스 제한을 의심하십시오. 또한 hybrid join 시나리오가 아니라면(여기서는 언급되지 않음) Azure AD join은 온프레미스 AD 또는 회사 네트워크에 대한 line-of-sight가 필요하지 않다는 점도 기억하십시오.

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

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

6
문제 6

App1이라는 Azure web app이 있습니다. App1에는 다음 표에 표시된 배포 슬롯이 있습니다:

diagram

webapp1-test에서 App1에 대한 여러 변경 사항을 테스트합니다. App1을 백업합니다. webapp1-test를 webapp1-prod로 스왑한 후 App1에 성능 문제가 발생하고 있음을 발견합니다. 가능한 한 빨리 App1을 이전 버전으로 되돌려야 합니다. 무엇을 해야 합니까?

App1을 다시 배포하면 아티팩트와 파이프라인이 준비되어 있는 경우 이전 버전을 복원할 수 있지만, 일반적으로 슬롯 스왑 롤백보다 느립니다. 빌드/릴리스 단계, 승인, 그리고 잠재적인 구성 드리프트가 포함될 수 있습니다. “가능한 한 빨리”를 강조하는 시험 시나리오에서 슬롯 스왑 직후라면, 다시 배포는 보통 최선의 선택이 아닙니다.

슬롯을 다시 스왑하는 것이 가장 빠른 롤백입니다. 첫 번째 스왑 이후 원래 프로덕션 버전은 스테이징 슬롯(webapp1-test)에 있습니다. 두 번째 스왑을 수행하면 최소한의 다운타임으로 프로덕션 트래픽을 해당 이전 버전으로 되돌릴 수 있습니다. 이것이 배포 슬롯의 주요 운영상 이점입니다: 빠르고 위험이 낮은 릴리스 및 신속한 롤백.

App1을 복제하면 web app의 복사본(선택적으로 구성 및 배포 슬롯 포함)을 생성하며, 이는 새 환경을 만들거나 설정을 복제하는 데 유용합니다. 그러나 잘못된 스왑 이후 프로덕션을 이전 버전으로 되돌리는 가장 빠른 방법은 아니며, 추가 리소스와 시간이 필요합니다.

백업을 복원하면 사이트 콘텐츠를 특정 시점으로 되돌릴 수 있지만, 슬롯 스왑 이후 가장 빠른 롤백 메커니즘은 아닙니다. 백업/복원 작업은 더 오래 걸릴 수 있고, 현재 콘텐츠를 덮어쓸 수 있으며, 즉각적인 배포 롤백보다는 복구 시나리오(실수로 삭제/손상)에 더 적합합니다.

문제 분석

핵심 개념: 이 문제는 Azure App Service 배포 슬롯과 스왑 동작을 테스트합니다. 배포 슬롯(Production, Staging 등)을 사용하면 동일한 앱의 두 버전을 나란히 실행하고 슬롯 스왑으로 트래픽을 전환할 수 있습니다. 이는 안전한 릴리스와 빠른 롤백을 지원합니다. 정답이 맞는 이유: webapp1-test를 webapp1-prod로 스왑한 후에도 프로덕션 앱의 “이전 버전”은 사라지지 않습니다. 해당 버전은 이제 다른 슬롯(webapp1-test)에 있습니다. 가장 빠르게 되돌리는 방법은 다시 슬롯 스왑을 수행하는 것으로, 이는 프로덕션 트래픽을 이전 빌드/구성 상태로 되돌리는 효과가 있습니다. 스왑은 일반적으로 수 초~수 분 내에 수행되며, 빠른 롤백을 위해 특별히 설계되었습니다. 주요 기능 및 모범 사례: - 슬롯 스왑은 슬롯 간에 콘텐츠(및 일부 설정)를 교환합니다. 또한 “swap with preview”를 사용하여 대상 슬롯을 워밍업하고 스왑 완료 전에 검증할 수 있습니다. - “Slot settings”(슬롯별로 지정된 설정)은 스왑 중에 이동하지 않으므로, 환경별 구성(예: test vs prod connection strings)을 안정적으로 유지하는 데 도움이 됩니다. - 이는 Azure Well-Architected Framework의 운영 우수성(operational excellence)과 일치합니다. 안전한 배포 관행을 사용하고, 다운타임을 최소화하며, 빠른 복구를 가능하게 합니다. 흔한 오해: - 백업은 재해 복구 및 특정 시점(point-in-time) 복원을 위한 것이지, 잘못된 배포에 대한 가장 빠른 롤백 수단이 아닙니다. 백업 복원은 더 오래 걸릴 수 있으며, 의도하지 않은 방식으로 콘텐츠/상태를 덮어쓸 수 있습니다. - 다시 배포하는 것은 더 느릴 수 있으며, 아티팩트를 다시 빌드하거나 파이프라인을 재실행해야 할 수 있습니다. 시험 팁: App Service에서 슬롯 스왑 직후 새 배포로 문제가 발생했다면, 가장 빠른 롤백은 거의 항상 “다시 스왑(swap back)”입니다. 백업은 데이터 손실/손상 시나 특정 시점으로 복원해야 할 때 사용하며, 빠른 릴리스 롤백을 위한 용도가 아닙니다.

7
문제 7

여러 부서에서 사용하는 Subscription1이라는 Azure 구독이 있습니다. Subscription1에는 다음 표의 리소스가 포함되어 있습니다: 이름 유형 storage1 Storage account RG1 Resource group container1 Blob container share1 File share 다른 관리자가 단일 Azure Resource Manager 템플릿을 사용하여 VM1이라는 가상 머신과 storage2라는 Azure Storage account를 배포합니다. 배포에 사용된 템플릿을 확인해야 합니다. 배포에 사용된 템플릿은 어떤 블레이드에서 확인할 수 있습니까?

VM1은 ARM 템플릿으로 생성된 리소스이지만, VM 블레이드는 배포에 사용된 전체 템플릿을 가져오는 기본 위치가 아닙니다. 일부 구성과 때로는 관련 배포 세부 정보를 볼 수는 있지만, 권위 있는 ARM 배포 레코드(템플릿, 파라미터, 작업)는 배포 범위(일반적으로 리소스 그룹)의 Deployments에서 추적됩니다.

B는 정답입니다. ARM template 세부 정보는 Deployments blade를 통해 배포 scope에서 접근하며, portal 기반 시험 시나리오에서는 일반적으로 resource group입니다. resource group에서 deployment record를 열어 template, parameters, 그리고 deployment operations를 볼 수 있습니다. 문제에서 배포가 RG1에서 발생했다고 명시적으로 말하지는 않지만, 제공된 보기 중 RG1이 유일한 resource group 옵션이므로 의도된 blade입니다. 이는 AZ-104 문제의 대부분의 resource 배포에서 Azure가 ARM deployment history를 표시하는 방식과 일치합니다.

storage2 또한 템플릿으로 생성된 리소스이지만, VM1과 마찬가지로 해당 리소스 블레이드는 배포를 수행한 전체 ARM 템플릿을 확인하는 표준 위치가 아닙니다. 배포 기록과 템플릿/파라미터 페이로드는 배포 범위(보통 리소스 그룹)의 Deployments 블레이드에서 저장 및 확인합니다.

container1은 Blob container(스토리지 데이터 플레인 리소스)입니다. 이는 ARM 템플릿 배포 기록의 일반적인 범위가 아니며, VM1과 storage2에 대한 ARM 배포 레코드를 제공하지 않습니다. Storage container가 ARM을 통해 생성되더라도 배포 레코드는 여전히 배포 범위(리소스 그룹 또는 구독)의 Deployments에서 액세스합니다.

문제 분석

핵심 개념: Azure Resource Manager (ARM) template 배포는 배포 scope, 가장 일반적으로는 resource group 관점에서 확인합니다. 배포 기록에는 template, parameters, 그리고 deployment operations가 저장되며, 해당 scope의 Deployments blade에서 이를 확인할 수 있습니다. 정답인 이유: virtual machine과 storage account 같은 리소스가 하나의 ARM template로 함께 배포된 경우, template는 VM이나 storage account 같은 개별 리소스에서 확인하지 않습니다. 대신, 배포된 리소스를 포함하는 resource group을 연 다음 Deployments 아래의 배포 항목을 검토하여 template를 확인합니다. 제공된 보기 중에서는 RG1만 resource group blade이므로 의도된 정답입니다. 주요 특징: - Resource group > Deployments에서는 deployment history, template, parameters, 그리고 operation details를 확인할 수 있습니다. - 개별 resource blade는 원래 ARM template를 확인하는 권한 있는 위치가 아닙니다. - ARM 배포는 subscription 같은 다른 scope에서도 수행될 수 있지만, 이는 보기에는 포함되어 있지 않습니다. 흔한 오해: - 사용자는 VM이나 storage account가 해당 template로 생성되었기 때문에 template를 직접 그 리소스에서 볼 수 있다고 자주 생각합니다. - blob container 같은 data-plane 객체는 ARM deployment history를 검토하는 위치가 아닙니다. - 핵심은 단순히 배포된 리소스 중 하나를 찾는 것이 아니라, 배포 scope를 식별하는 것입니다. 시험 팁: AZ-104에서 배포에 사용된 template를 어디서 확인하는지 묻는 문제가 나오면, 배포 scope의 Deployments blade를 떠올리세요. resource group이 유일한 scope 관련 보기라면, 일반적으로 그것이 정답입니다.

8
문제 8

기존 virtual machine을 기반으로 한 Azure Resource Manager template을 다운로드합니다. 해당 template은 100개의 virtual machine을 배포하는 데 사용됩니다. administrative password를 참조하도록 template을 수정해야 합니다. password가 plain text로 저장되지 않도록 해야 합니다. password를 저장하기 위해 무엇을 생성해야 합니까?

정답입니다. Azure Key Vault는 administrative passwords와 같은 secrets를 안전하게 저장하도록 설계되었으며 ARM templates가 배포 시점에 해당 secrets를 참조할 수 있게 합니다. access policy(또는 RBAC)는 deployment identity가 secret을 검색할 수 있도록 권한(예: Secrets: Get)을 부여합니다. 이는 template 또는 parameter files에 password를 hardcoding하거나 plain text로 저장하는 것을 방지하며 auditing 및 rotation을 지원합니다.

오답입니다. Azure Storage account는 secrets management service가 아닙니다. SAS, access keys 또는 RBAC를 사용해 접근을 제한할 수는 있지만, password를 blob/file에 저장하는 것은 여전히 데이터를 저장하는 것이며 일반적으로 encryption, access patterns 및 rotation을 직접 관리해야 합니다. ARM templates는 secret references를 위해 Key Vault와 네이티브로 통합되며, storage는 best-practice 솔루션이 아닙니다.

오답입니다. Recovery Services vault 및 backup policy는 workloads에 대한 backup/restore 및 disaster recovery(Azure Backup, Azure Site Recovery)에 사용됩니다. ARM template parameters에 대한 secret storage 또는 secure retrieval 메커니즘을 제공하지 않습니다. 이 옵션은 data protection/backup과 credential 및 secret management를 혼동한 것입니다.

오답입니다. Azure AD Identity Protection은 identity risks(risky sign-ins, compromised accounts)를 탐지하고 개선하는 데 초점을 둡니다. Azure Policy는 리소스에 대한 governance rules를 강제합니다. 어느 서비스도 VM admin passwords와 같은 secrets를 저장하거나 ARM template secret references를 제공하기 위한 용도가 아닙니다. 이는 governance 및 security posture 도구이지 secret storage가 아닙니다.

문제 분석

핵심 개념: 이 문제는 compute 리소스를 대규모로 배포할 때 Azure Resource Manager (ARM) templates에서 secret을 안전하게 처리하는 방법을 평가합니다. ARM templates는 선언적 JSON 파일이며, 자격 증명을 직접 포함(파라미터로 포함하더라도)하면 source control, template export, deployment history 또는 logs를 통해 노출될 위험이 있습니다. 정답이 맞는 이유: Azure Key Vault는 secrets(passwords, keys, certificates)를 저장하고 접근을 제어하기 위해 설계된 Azure의 전용 서비스입니다. ARM template에서는 Key Vault reference가 포함된 parameter를 사용하여(또는 linked template/secure parameter 패턴을 사용하여) Key Vault secret을 참조할 수 있습니다. 이를 통해 password가 template 파일에 plain text로 저장되는 것을 방지할 수 있습니다. access policy(또는 vault 구성에 따라 Azure RBAC permissions)는 deployment identity(user, service principal 또는 managed identity)가 배포 시점에 secret을 읽을 수 있도록 권한을 부여합니다. 주요 기능 및 best practices: - Secret storage: Key Vault는 secrets를 at rest에서 암호화하여 저장하며 versioning 및 rotation을 지원합니다. - Access control: Key Vault access policies 또는 RBAC를 통해 least privilege를 적용합니다(예: secrets에 대한 “Get” permission). ARM deployments의 경우 deploying principal이 secret을 읽을 수 있도록 보장해야 합니다. - Secure parameters: ARM은 “secureString” parameter type을 지원하지만, 이는 outputs에서 값이 표시되는 것을 방지할 뿐입니다. 값을 hardcode하거나 parameter files에 커밋하면 값이 어디에 저장되는지 문제를 해결하지 못합니다. Key Vault가 권장되는 안전한 외부 저장소입니다. - Well-Architected Framework alignment: 이는 Security pillar(secrets 보호, least privilege, 중앙화된 secret management) 및 Operational Excellence(수동 password 처리 없이 반복 가능한 deployments)를 지원합니다. 흔한 오해: - “secureString이면 충분하다”: 배포 중 값 마스킹에는 도움이 되지만, parameter file 또는 template에 값을 저장하면 여전히 노출될 수 있습니다. Key Vault는 template에 secret을 저장하지 않도록 합니다. - “Storage account와 policies”: Storage는 secret management system이 아니며, access policies는 secret별 제어, auditing 또는 rotation을 제공하지 않습니다. Exam tips: ARM/Bicep deployments에서 passwords, connection strings 또는 keys가 필요할 때, 정답은 거의 항상 Azure Key Vault입니다. 기억할 점: Key Vault references를 사용하고 deployment identity에 secrets를 읽을 권한을 부여하세요. 이는 특히 대규모 deployments(예: 100 VMs)에서 credentials를 중앙화하고 관리 가능하게 유지하는 데 중요합니다.

9
문제 9

HOTSPOT - 다음 표에 표시된 리소스 그룹을 포함하는 Azure 구독이 있습니다.

diagram

RG1에는 다음 표에 표시된 리소스가 포함되어 있습니다.

VM1은 실행 중이며 NIC1 및 Disk1에 연결됩니다. NIC1은 VNET1에 연결됩니다. RG2에는 East US 위치에 있는 IP2라는 공용 IP 주소가 포함되어 있습니다. IP2는 가상 머신에 할당되어 있지 않습니다. 다음 각 문에 대해 문이 참이면 Yes를 선택합니다. 그렇지 않으면 No를 선택합니다. 참고: 각 정답 선택은 1점입니다. 핫 영역:

파트 1:

storage1은 West US에 위치한 Storage account입니다.

아닙니다. resource group의 location은 resource group의 metadata가 저장되는 위치만 결정하며, group 내부의 resource 위치를 결정하지는 않습니다. 시나리오에서 storage1의 location이 명시적으로 stated되지 않았으므로, 단지 RG1에 있다는 이유만으로 storage1이 West US에 있다고 결론내릴 수 없습니다. 따라서 해당 진술은 false이며, move 관련 진술은 resource group region이 아니라 resource 지원 여부를 기준으로 평가해야 합니다.

파트 2:

VNet1은 West US에 위치한 Virtual network입니다.

아닙니다. virtual network의 location은 resource group에서 상속되는 것이 아니라 그 자체의 속성입니다. 이 시나리오에서는 VNet1이 West US에 있다고 전혀 명시하지 않으므로, 해당 진술이 참이라고 확인할 수 없습니다. NIC와 VM은 사용하는 VNet과 regional alignment가 맞아야 하지만, 그렇다고 해서 resource group의 location만으로 VNet의 region을 추론할 수는 없습니다.

파트 3:

NIC1은 West US에 위치한 Network interface입니다.

아닙니다. network interface는 자체 Azure region을 가지며, resource group의 region을 상속하지 않습니다. NIC는 연결된 virtual network/subnet 및 VM과 동일한 region에 있어야 하지만, 이 시나리오에서는 해당 resource들의 위치가 명시적으로 제공되지 않습니다. RG1이 West US에 있다는 사실만으로 NIC1이 West US에 있다고 증명하기에는 충분하지 않으므로, 이 진술은 거짓입니다.

파트 4:

Disk1은 West US에 위치한 Disk입니다.

아닙니다. Managed disks는 regional resources이지만, 해당 region은 resource group의 location에 의해 결정되지 않습니다. 연결된 managed disk는 해당 VM과 동일한 region에 있어야 하지만, 이 시나리오에서는 VM1의 region이 명시적으로 언급되지 않습니다. 따라서 Disk1이 West US에 있다고 단정할 수 없으므로, 이 진술은 거짓입니다.

파트 5:

VM1은 West US에 위치한 Virtual machine입니다.

아니요. Virtual machines에는 자체 location 속성이 있으며, 해당 속성은 resource group의 location과 독립적입니다. VM1이 RG1에 있다는 사실이 VM1이 West US에 있다는 의미는 아닙니다. Azure에서는 resource group 내의 resources가 서로 다른 regions에 존재할 수 있기 때문입니다. 시나리오에서 VM1의 region을 명시적으로 언급하지 않았으므로, 해당 진술은 거짓입니다.

파트 6:

storage1을(를) RG2로 이동할 수 있습니다.

예. 동일한 subscription 내에서 resource group 간에 storage account를 이동할 수 있습니다. 이는 거버넌스, 청구, 또는 lifecycle management를 위해 리소스를 재구성할 때 사용하는 일반적인 Azure Resource Manager 작업입니다. 중요한 제약 사항: 이동하더라도 storage account의 location은 변경되지 않습니다(예: West US로 유지). 또한 이동을 차단하는 lock 또는 policy가 없는지 확인해야 합니다. 그리고 일부 리소스는 함께 이동해야 하는 dependency가 있을 수 있지만, storage account는 일반적으로 이동이 지원됩니다. 따라서 storage1을 RG2로 이동하는 것은 허용됩니다(동일한 subscription이고 lock이 없다는 가정하에). 변경되는 것은 resource group 할당뿐입니다.

파트 7:

NIC1을 RG2로 이동할 수 있습니다.

아니요. NIC1은 VM1에 연결되어 있습니다(VM1이 “NIC1에 연결됨”). VM에서 사용 중인 NIC는 종속 리소스이므로, 연결된 상태로는 일반적으로 단독으로 다른 resource group으로 이동할 수 없습니다. Azure에서 리소스를 이동할 때는 필요한 모든 종속 리소스를 동일한 이동 작업에 포함해야 합니다. VM의 경우 일반적으로 VM 리소스, 해당 NIC(들), 그리고 경우에 따라 기타 종속성이 포함됩니다. NIC1만 RG2로 이동하려고 하면 VM1이 여전히 이를 참조하고 있기 때문에 실패합니다. 따라서 이 시나리오에서는 NIC1만 단독으로 RG2로 이동할 수 없습니다. 올바른 방법은 VM1과 그 종속 리소스를 함께 이동하는 것입니다(또는 플랫폼과 구성에서 허용한다면 NIC를 분리하는 방법이 있지만, 여기서는 그런 내용이 암시되어 있지 않습니다).

파트 8:

IP2를 RG1으로 이동하면 IP2의 위치가 변경됩니다.

아니요. 리소스를 리소스 그룹 간에 이동해도 리소스의 location/region은 변경되지 않습니다. location 속성은 Public IP addresses와 같은 regional 리소스의 경우 생성 시점에 설정됩니다. IP2는 East US에 있다고 명시되어 있으며 현재 RG2에 있습니다. IP2를 RG1으로 이동하면 리소스 그룹만 변경되고, IP2는 East US public IP로 그대로 유지됩니다. 이는 AZ-104의 핵심 개념입니다. 리소스 그룹은 관리 컨테이너이지, 리소스를 다른 region으로 재배포하는 메커니즘이 아닙니다. 리소스의 region을 변경하려면 일반적으로 대상 region에서 리소스를 다시 생성해야 하며(또는 서비스별 마이그레이션 방법을 사용해야 하며), 단순히 다른 리소스 그룹으로 이동하는 것만으로는 불가능합니다.

10
문제 10

HOTSPOT - Subscription1 및 Subscription2라는 Azure subscription이 있습니다. Subscription1에는 다음 resource group이 있습니다:

diagram

RG1에는 West Europe 위치에 App1이라는 web app이 포함되어 있습니다. Subscription2에는 다음 resource group이 포함되어 있습니다: Name Region Lock type RG3 East Europe Delete RG4 Central US none 다음 각 문장에 대해 문장이 참이면 Yes를 선택합니다. 그렇지 않으면 No를 선택합니다. 참고: 각 정답 선택은 1점입니다. Hot Area:

파트 1:

App1을 RG2로 이동할 수 있습니다

RG2에 리소스 그룹 범위에서 ReadOnly 관리 잠금이 적용되어 있으므로 App1을 RG2로 이동할 수 없습니다. ReadOnly 잠금은 리소스를 볼 수는 있지만 리소스 그룹의 콘텐츠를 수정하는 작업(그룹에 리소스를 추가하거나 리소스를 그룹으로 이동하는 작업 포함)은 수행할 수 없음을 의미합니다. 이동 작업은 쓰기 작업으로 처리됩니다(리소스의 resourceGroup 속성을 변경하고 ARM 메타데이터를 업데이트함). 따라서 차단됩니다. RG2가 West Europe(App1과 동일)에 있다는 사실은 도움이 되지 않습니다. 리소스 그룹 위치는 해당 리소스가 있을 수 있는 리전을 제한하지 않으며, RG 간 이동은 어차피 리소스의 리전을 변경하지 않습니다. 결정적인 요인은 잠금입니다.

파트 2:

App1은 RG3로 이동할 수 있습니다

App1은 RG3로 이동할 수 있습니다. RG3에는 Delete (CanNotDelete) 잠금이 있으며, 이는 리소스 그룹 또는 그 안의 리소스 삭제를 방지하지만 업데이트 또는 리소스를 그룹으로 이동하는 것과 같은 write 작업은 방지하지 않습니다. 따라서 잠금 유형이 이동을 차단하지 않습니다. RG3가 다른 region(East Europe)에 있더라도 이는 차단 요인이 아닙니다. 리소스 그룹 location은 리소스에 대한 배치 제약이 아니며, Web App을 리소스 그룹 간에 이동해도 Web App의 region은 변경되지 않습니다(App1은 West Europe에 그대로 유지됨). cross-subscription 이동의 주요 전제는 Subscription1과 Subscription2가 동일한 Azure AD tenant에 있고 충분한 권한이 있다는 것이며, 문제에서 별도로 언급하지 않는 한 일반적으로 이러한 전제 조건이 충족된 것으로 가정합니다.

파트 3:

App1은 RG4로 이동할 수 있습니다

RG4에는 management lock이 없으므로 리소스 이동과 같은 write 작업을 막는 governance control이 없어 App1을 RG4로 이동할 수 있습니다. RG3와 마찬가지로 RG4가 Central US로 표시되어 있다는 사실은 West Europe 리소스를 해당 resource group에 배치하는 것을 막지 않습니다. resource group의 region은 리소스 region에 대한 제약이 아니며, 이동은 Web App을 Central US로 재배치하지도 않습니다. 이는 cross-subscription 이동(Subscription1에서 Subscription2로)입니다. AZ-104에서는 일반적인 사전 요구 사항을 기억하세요. 두 subscription이 동일한 Azure AD tenant에 있어야 하고, source 및 target scope에 대해 적절한 RBAC 권한이 있어야 하며, 해당 resource type이 이동을 지원해야 합니다. App Service Web Apps는 일반적인 조건에서 resource group 및 subscription 이동을 지원합니다.

다른 모의고사

Practice Test #1

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

Practice Test #2

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

Practice Test #3

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를 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.