Practice Test #8
50개 문제와 100분 시간 제한으로 실제 시험을 시뮬레이션하세요. AI 검증 답안과 상세 해설로 학습하세요.
AI 기반
3중 AI 검증 답안 및 해설
모든 답안은 3개의 최고 AI 모델로 교차 검증하여 최고의 정확도를 보장합니다. 선택지별 상세 해설과 심층 문제 분석을 제공합니다.
기출 문제
Plan1이라는 App Service plan과 webapp1이라는 Azure web app을 생성합니다. 스테이징 슬롯을 생성하는 옵션을 사용할 수 없다는 것을 발견합니다. Plan1에 대해 스테이징 슬롯을 생성해야 합니다. 가장 먼저 무엇을 해야 합니까?
정답입니다. App Service plan을 scale up하면 pricing tier(SKU)가 변경됩니다. Deployment slots는 지원되는 tier(일반적으로 Standard 이상)에서만 사용할 수 있습니다. 슬롯 생성 옵션을 사용할 수 없다면, Plan1을 업그레이드하여 기능을 활성화하는 것이 선행 조건입니다. 이는 plan 수준 변경이며 해당 plan의 모든 앱에 적용되므로, 이후 webapp1에서 스테이징 슬롯을 추가할 수 있습니다.
오답입니다. Application settings(app settings/connection strings) 수정은 런타임 구성을 변경하며 slot settings로 표시할 수는 있지만, deployment slots 기능을 활성화하지는 않습니다. 포털에서 슬롯 생성을 허용하지 않는다면, 제한은 거의 확실히 App Service plan tier 수준에 있으며, Application settings의 누락이나 오류 때문이 아닙니다.
오답입니다. Custom domain 추가는 deployment slots와 관련이 없습니다. Custom domain과 TLS 바인딩은 앱 수준 기능이며 슬롯을 생성할 수 있는지 여부를 제어하지 않습니다. 슬롯에서 custom domain을 사용할 수는 있지만(테스트 용도로 자주 사용), 먼저 슬롯을 지원하는 tier에 있어야 하며, 도메인 구성은 슬롯 생성 기능을 활성화하기 위한 선행 조건이 아닙니다.
오답입니다. Scaling out은 더 많은 부하를 처리하고 가용성을 개선하기 위해 인스턴스 수를 늘리는 것(수평 확장)입니다. 이는 App Service plan SKU를 변경하지 않으므로 deployment slots처럼 tier에 의존하는 기능을 활성화하지 못합니다. 슬롯을 사용할 수 없다면 scaling out을 해도 해당 옵션이 나타나지 않습니다.
문제 분석
핵심 개념: Deployment slots는 Azure App Service 기능으로, 동일한 App Service plan 내에서 web app의 여러 버전(프로덕션, 스테이징 등)을 실행할 수 있게 해줍니다. 슬롯은 안전한 배포(워밍업 후 swap), 프로덕션과 유사한 조건에서의 테스트, 빠른 롤백을 가능하게 합니다. 슬롯 사용 가능 여부는 주로 App Service plan의 pricing tier에 따라 결정됩니다. 정답이 맞는 이유: 스테이징 슬롯 생성 옵션을 사용할 수 없다면, 가장 흔한 원인은 Plan1이 deployment slots를 지원하지 않는 tier에 있기 때문입니다(예: Free (F1) 또는 Shared (D1), 그리고 많은 시험 문맥에서는 Basic (B1/B2/B3)도 슬롯을 지원하지 않는 것으로 취급). 슬롯을 사용하려면 deployment slots를 지원하는 tier(일반적으로 Standard (S1+) 이상, 예: Premium v2/v3)로 App Service plan을 이동해야 합니다. 이는 App Service plan 블레이드에서 scale up(가격 tier 변경)을 통해 수행합니다. 따라서 첫 번째 조치는 Plan1을 scale up하는 것입니다. 주요 기능 및 모범 사례: Scaling up은 plan의 SKU를 변경하여 deployment slots, autoscale 기능(티어에 따라 다름), CPU/메모리 증가 및 기타 플랫폼 기능을 사용할 수 있게 합니다. Azure Well-Architected Framework 관점에서 deployment slots는 Reliability(안전한 릴리스/롤백)와 Operational Excellence(반복 가능한 배포, 다운타임 감소)를 향상시킵니다. Scale up 이후 webapp1에서 스테이징 슬롯을 생성할 수 있으며, 필요에 따라 slot settings(슬롯에 “고정”되는 설정)를 구성하고 swap with preview를 사용할 수 있습니다. 흔한 오해: Scaling out(인스턴스 추가)은 용량과 가용성을 개선하지만 슬롯 같은 기능을 활성화하지는 않습니다. App settings와 custom domain은 앱 수준 구성으로, 플랫폼에서 deployment slots 기능을 노출하는지 여부에 영향을 주지 않습니다. 시험 팁: App Service에서 포털 기능이 “없어 보일” 때는 먼저 App Service plan tier/SKU를 확인하십시오. 기억할 점: 기능 사용 가능 여부(슬롯, 백업, VNet integration 옵션 등)는 앱별 설정이 아니라 plan tier에 의해 제어되는 경우가 많습니다. AZ-104에서는 “deployment slots”를 Standard 이상과 연결하고, tier를 변경하는 동작으로 “scale up”을 연관 지으십시오.
DRAG DROP - Azure 구독에 storage account가 포함되어 있습니다. Windows Server 2016을 실행하는 Server1이라는 온-프레미스 서버가 있습니다. Server1에는 2TB의 데이터가 있습니다. Azure Import/Export 서비스를 사용하여 데이터를 storage account로 전송해야 합니다. 어떤 순서로 작업을 수행해야 합니까? 답하려면 작업 목록의 모든 작업을 답변 영역으로 이동하고 올바른 순서로 정렬하십시오. 참고: 정답 선택지의 순서는 하나 이상이 맞을 수 있습니다. 선택한 올바른 순서 중 어떤 것이든 정답으로 인정됩니다. 선택 및 배치:
아래 이미지에서 올바른 답(들)을 선택하세요.
Pass. Azure Import/Export(Azure로 import)의 올바른 작업 순서는 다음과 같습니다: 1) Server1에 외장 디스크를 연결하고 WAImportExport.exe를 실행하여 데이터를 복사하고 디스크를 암호화하면서 journal/metadata를 생성합니다. 2) Azure portal에서 import job을 생성합니다(또는 1단계 전에 수행할 수도 있으며, 문제의 참고 사항에 따르면 여러 순서가 정답일 수 있습니다). 3) Azure portal에서 드라이브 세부 정보(journal file 정보/drive IDs, BitLocker keys, 그리고 일반적으로 배송/추적 정보)를 사용해 import job을 업데이트합니다. 4) Server1에서 외장 디스크를 분리한 다음, job에서 제공된 Azure datacenter 주소로 디스크를 배송합니다. 이 순서가 맞는 이유: WAImportExport는 디스크를 준비하고 Azure가 필요로 하는 정보를 생성하므로 배송 전에 실행되어야 합니다. Microsoft가 드라이브를 잠금 해제하고 처리할 수 있도록 job 업데이트가 필요합니다. 또한 job에서 올바른 datacenter 목적지를 받은 뒤에, 준비가 완료된 후에 배송해야 합니다.
Windows Server 2016을 실행하는 Azure virtual machine 5대가 있습니다. 해당 virtual machine은 web server로 구성되어 있습니다. virtual machine에 대해 load balancing 서비스를 제공하는 LB1이라는 Azure load balancer가 있습니다. 방문자가 각 요청마다 동일한 web server에서 서비스를 받도록 해야 합니다. 무엇을 구성해야 합니까?
Floating IP(Direct Server Return)를 Enabled로 설정하면 특정 구성에서 Azure Load Balancer가 destination IP를 처리하는 방식이 변경되며, SQL Always On Availability Group listener 또는 특정 appliance/DSR 설계 같은 시나리오에서 흔히 사용됩니다. 이는 요청 간 client-to-backend affinity를 제공하지 않습니다. 따라서 방문자가 각 요청마다 일관되게 동일한 web server에 도달하도록 보장하지 못합니다.
Floating IP를 Disabled로 설정하는 것은 많은 load-balancing rule에서의 기본/일반적인 구성일 뿐입니다. Enabled로 설정하는 것과 마찬가지로 이 설정은 session affinity와 관련이 없습니다. 동일한 client의 후속 요청이 동일한 backend VM으로 전달되는지 여부에 영향을 주지 않습니다. 이는 DSR 관련 시나리오에서의 특정 packet 처리 동작에만 영향을 줍니다.
health probe는 load balancer가 backend VM의 health를 감지하고 비정상 instance로 트래픽을 보내지 않도록 하는 데 필요합니다. 신뢰성 측면에서 중요하지만, probe는 실패한 node를 제외하는 것 외에 정상 instance 간 트래픽이 어떻게 분산되는지를 제어하지 않습니다. “sticky sessions”를 제공하거나 클라이언트의 요청이 동일한 VM으로 가도록 보장하지 않습니다.
Session persistence를 Client IP and Protocol로 설정하면 클라이언트 IP address와 transport protocol을 기반으로 source affinity가 활성화됩니다. 이는 동일한 protocol을 사용하는 동일한 클라이언트의 요청이 일관되게 동일한 backend VM으로 hash된다는 뜻이며, 각 요청마다 방문자가 동일한 web server에서 서비스되어야 한다는 요구 사항을 충족합니다. Azure Load Balancer에서 이것이 Layer 4에서 sticky 동작을 위한 관련 기능입니다. 특히 client source뿐 아니라 protocol별로도 트래픽을 구분하는 persistence가 필요할 때 적합합니다.
문제 분석
핵심 개념: 이 문제는 Azure Load Balancer의 session persistence에 관한 것으로, 이는 동일한 클라이언트의 요청이 일관되게 동일한 backend VM으로 전송되는지를 제어합니다. 여러 요청에 걸쳐 방문자가 동일한 web server에 유지되도록 하려면 Floating IP나 health probe 같은 설정이 아니라 persistence mode를 사용해야 합니다. 여기서 올바른 선택은 Session persistence를 Client IP and Protocol로 설정하는 것이며, 이는 source IP와 protocol을 load-balancing hash에 사용하여 동일한 protocol을 사용하는 동일한 클라이언트가 backend instance가 정상 상태인 동안 동일한 backend instance로 전달되도록 합니다. 흔한 오해는 health probe나 Floating IP가 stickiness를 만든다는 것이지만, probe는 backend 상태만 판단하고 Floating IP는 direct server return 시나리오를 위한 것입니다. 시험 팁: Azure Load Balancer에서 'same server' 또는 'sticky sessions' 요구 사항이 있으면 session persistence를 떠올려야 하며, 반면 Application Gateway는 HTTP/HTTPS에 대해 cookie-based affinity를 사용합니다.
AKS1이라는 Azure Kubernetes Service (AKS) 클러스터가 있습니다. AKS1에 대해 cluster autoscaler를 구성해야 합니다. 어떤 두 가지 도구를 사용해야 합니까? 각 정답은 완전한 솔루션을 제시합니다. 참고: 각 정답 선택은 1점입니다.
kubectl은 클러스터 내부의 Kubernetes API 객체(pod, deployment, service, HPA 리소스)를 관리합니다. AKS cluster autoscaler 활성화는 kubectl로 Kubernetes 매니페스트를 적용하여 구성하는 것이 아니라, Azure 관리 plane을 통해 제어되는 AKS/node pool 설정입니다. kubectl은 영향(보류 중인 pod, 노드 변경)을 관찰하는 데는 사용할 수 있지만, autoscaler 기능 자체를 구성하는 도구는 아닙니다.
Azure CLI는 az aks 및 az aks nodepool 명령을 통해 AKS autoscaling 구성을 지원합니다. node pool별로 cluster autoscaler를 활성화/비활성화하고 최소/최대 노드 수를 설정할 수 있습니다(예: az aks nodepool update --enable-cluster-autoscaler --min-count --max-count). 이는 완전하고 지원되는 솔루션이며, AZ-104에서 AKS 관리 작업으로 자주 출제됩니다.
Set-AzVm은 독립 실행형 Azure virtual machine을 관리하는 데 사용됩니다. AKS 노드는 일반적으로 AKS가 관리하는 VM Scale Set의 일부이며, 직접 VM을 관리하는 방식은 cluster autoscaler를 활성화하는 올바른 접근이 아닙니다. Autoscaler는 개별 VM을 수정하는 것이 아니라 AKS node pool 수준에서 AKS 도구로 구성합니다.
Azure portal은 AKS node pool에서 autoscaling을 켜고 최소 및 최대 노드 수를 지정하여 cluster autoscaler를 활성화하는 지원되는 UI 워크플로를 제공합니다. 이는 스크립팅 없이 autoscaler를 구성하는 완전한 솔루션입니다. portal 기반 구성이 허용되고 자주 참조되는 전형적인 AZ-104 작업과도 부합합니다.
Set-AzAks는 시험에서 기대하는 방식으로 AKS cluster autoscaler를 구성하는 표준 PowerShell cmdlet이 아닙니다. 실제로 AKS PowerShell은(모듈/버전에 따라) Set-AzAksCluster 또는 node pool 관련 cmdlet을 사용하지만, AZ-104에서는 AKS 구성을 위해 일반적으로 portal과 Azure CLI(az aks)를 출제합니다. 따라서 이 옵션은 신뢰할 수 있거나 인지되는 완전한 솔루션이 아닙니다.
문제 분석
핵심 개념: 이 문제는 AKS Cluster Autoscaler를 활성화하고 구성하는 방법을 평가합니다. Cluster Autoscaler는 보류 중인 pod 및 노드 사용률 제약 조건에 따라 node pool의 노드 수를 자동으로 늘리거나 줄이는 AKS 기능입니다. 이는 node pool 수준(최소/최대 노드 수)에서 구성되며, Kubernetes 매니페스트가 아니라 AKS control plane에서 관리됩니다. 정답이 맞는 이유: cluster autoscaler는 (1) Azure CLI의 az aks 명령(예: az aks nodepool update --enable-cluster-autoscaler --min-count X --max-count Y 또는 생성 시)과 (2) Azure portal에서 node pool을 편집하여 autoscaling을 활성화하고 최소/최대 노드 수를 지정하는 방식으로 구성할 수 있습니다. 둘 다 AKS1에 대해 autoscaler를 구성하는 완전하고 지원되는 방법입니다. 주요 기능, 구성 및 모범 사례: Cluster autoscaler는 node pool별로 동작하므로, 일반적으로 확장 가능한 워크로드를 호스팅하는 system 및/또는 user node pool에서 이를 활성화합니다. 비용과 용량을 제어하기 위해 적절한 최소/최대 경계를 설정해야 하며, 이는 Azure Well-Architected Framework 원칙(비용 최적화 및 안정성)과도 일치합니다. quota(vCPU 제한), 지역 용량, node pool 제약 조건(VM SKU 가용성, pool당 최대 노드 수, subnet IP 용량)을 고려하세요. Autoscaler는 Horizontal Pod Autoscaler (HPA)와 다릅니다. HPA는 pod를 확장하고, cluster autoscaler는 pod 스케줄링을 충족하기 위해 노드를 확장합니다. 일반적인 오해: 많은 사람이 autoscaling이 Kubernetes와 관련되어 있으므로 kubectl을 사용한다고 가정합니다. 그러나 AKS에서 cluster autoscaler 구성은 kubectl로 적용하는 Kubernetes 객체가 아니라 node pool에 대한 Azure 관리 설정입니다. 또 다른 함정은 노드가 VM/VMSS이므로 일반 VM cmdlet(Set-AzVm)을 선택하는 것입니다. 하지만 AKS는 노드 관리를 추상화하므로 노드 인스턴스를 직접 관리해서는 안 됩니다. 시험 팁: AZ-104에서는 AKS 운영 설정(node pool, autoscaling, 업그레이드)은 일반적으로 Azure portal 또는 Azure CLI(az aks / az aks nodepool)로 구성한다는 점을 기억하세요. kubectl은 클러스터 내부의 Kubernetes 리소스(deployment, service, HPA)를 다루는 데 사용하며, cluster autoscaler 같은 AKS 관리 기능을 활성화하는 데 사용하지 않습니다.
Vault1이라는 Recovery Services vault가 있는 Azure 구독이 있습니다. 이 구독에는 다음 표에 표시된 가상 머신이 포함되어 있습니다:
매일 밤 23:00에 백업이 수행되도록 예약하려고 합니다. Azure Backup을 사용하여 백업할 수 있는 가상 머신은 무엇입니까?
정답입니다. VM1과 VM3는 Windows Server 2012 R2와 Ubuntu Server 18.04 LTS가 Azure VM backup에 대해 지원되는 operating systems이므로 확실히 지원됩니다. VM2도 Windows Server 2016이 지원되는 server OS이므로 지원되며, auto-shutdown 설정이 있다고 해서 backup 대상에서 제외되지는 않습니다. VM4는 Windows 10이 client operating system이므로 제외되며, Azure IaaS VM protection을 위한 지원되는 Azure VM backup 매트릭스에 포함되지 않습니다.
오답입니다. 이 선택지는 VM4를 잘못 포함하고 있습니다. VM1, VM2, VM3는 Azure Backup에 대해 지원되지만, Windows 10은 client OS이므로 지원되는 Windows Server 및 Linux workloads와 같은 방식으로 Azure VM backup에서 지원되지 않습니다. 19:00의 auto-shutdown은 VM2를 backup 대상에서 제외하지 않지만, 그렇다고 VM4가 지원되는 것은 아닙니다.
오답입니다. VM1과 VM2는 backup할 수 있지만, Ubuntu Server 18.04 LTS는 Azure VM backup에 대해 지원되는 Linux distribution이므로 VM3도 보호할 수 있습니다. 따라서 VM3를 제외한 것은 잘못되었습니다. 제외되어야 하는 유일한 VM은 Windows 10 client OS를 사용하는 VM4입니다.
오답입니다. VM1은 지원되지만, 유일하게 eligible한 VM은 아닙니다. VM2도 Windows Server 2016이 지원되므로 지원되며, VM3도 Ubuntu Server 18.04 LTS가 지원되는 Linux 매트릭스에 포함되므로 지원됩니다. 이 선택지는 유효한 지원 workloads를 무시하고 답을 지나치게 좁게 한 잘못이 있습니다.
문제 분석
핵심 개념: 이 문제는 Recovery Services vault에서 Azure IaaS virtual machines에 대한 Azure Backup의 지원 매트릭스를 테스트합니다. 핵심 판단 기준은 각 VM의 operating system이 Azure VM backup에 대해 지원되는지 여부이며, VM에 auto-shutdown이 활성화되어 있는지 여부가 아닙니다. 정답인 이유: VM1, VM2, VM3는 Azure Backup이 Windows Server 및 Ubuntu Server 18.04 LTS와 같은 지원되는 Linux distributions를 실행하는 Azure VMs를 지원하므로 지원됩니다. 19:00의 auto-shutdown은 23:00의 backup 대상에서 VM2를 제외하지 않습니다. Azure Backup은 Azure VMs가 stopped/deallocated 상태여도 backup할 수 있기 때문이며, 이 경우 backup은 application-consistent가 아니라 crash-consistent일 수 있습니다. VM4는 Windows 10이 client OS이기 때문에 지원되지 않으며, Azure VM backup 지원은 지원되는 server 및 Linux workloads를 대상으로 합니다. 주요 기능: Azure VMs용 Azure Backup은 Recovery Services vault와 policy-based scheduling을 사용합니다. 지원되는 Azure IaaS VMs에는 Windows Server editions와 지원되는 Linux distributions가 포함됩니다. Backup consistency는 VM이 실행 중인지 여부에 따라 달라질 수 있지만, backup 가능 여부는 주로 지원 매트릭스에 따라 결정됩니다. 일반적인 오해: 흔한 실수는 auto-shutdown이 저녁 늦게 실행되는 backups를 막는다고 가정하는 것입니다. 또 다른 자주 나오는 함정은 Windows 10과 같은 Windows client operating systems를 Azure VM backup 지원 측면에서 Windows Server와 동일하게 취급하는 것입니다. 시험 문제는 지원되는 server OS와 지원되지 않는 client OS를 섞어 지원 매트릭스에 대한 지식을 테스트하는 경우가 많습니다. 시험 팁: AZ-104에서는 모든 Azure VMs가 backup 대상이라고 가정하지 말고, 항상 Azure Backup의 지원 매트릭스와 대조하여 workload 지원 여부를 확인하세요. Server operating systems와 client operating systems를 구분하세요. 또한 power state는 backup consistency에 영향을 주지만, 반드시 backup 수행 가능 여부 자체를 결정하는 것은 아니라는 점도 기억하세요.
이동 중에도 모든 문제를 풀고 싶으신가요?
Cloud Pass를 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
HOTSPOT - Subscription1이라는 Azure 구독이 있습니다. Subscription1에서 share1이라는 Azure file share를 생성합니다. 다음 전시에서와 같이 SAS1이라는 shared access signature (SAS)를 생성합니다.
답하려면, 답안 영역에서 적절한 옵션을 선택하십시오. 참고: 각 정답 선택은 1점입니다. 핫 영역:
아래 이미지에서 올바른 답(들)을 선택하세요.
Pass가 적절한 이유는, 제시된 자료(exhibit)가 결과를 결정론적으로 판단하기에 충분한 정보를 제공하기 때문입니다. SAS 설정에 다음이 명확히 표시되어 있습니다: - Allowed services: File (체크됨) - Allowed resource types: Service, Container, Object (모두 체크됨) - Allowed permissions: Read, Write, List (체크됨) - Start/End: Sep 1, 2018 2:00 PM ~ Sep 14, 2018 2:00 PM - Allowed IPs: 193.77.134.10–193.77.134.50 - Allowed protocols: HTTPS only 이러한 제약 조건을 바탕으로 각 시나리오(날짜/시간 + 클라이언트 IP + 도구/프로토콜)를 평가하여 액세스가 허용되는지, 그리고 허용된다면 어떤 권한이 적용되는지를 결정할 수 있습니다. 따라서 “Pass”를 선택하는 것은 타당하며, 모호하거나 핵심 세부 정보가 누락된 상황이 아닙니다.
2018년 9월 2일에 IP 주소가 193.77.134.1인 컴퓨터에서 Microsoft Azure Storage Explorer를 실행하고 SAS1을 사용하여 storage account에 연결하면, 당신은 ______.
2018년 9월 2일에는 SAS 시간 범위가 유효합니다(9월 1일에 시작하여 9월 14일에 종료). 그러나 컴퓨터의 IP 주소 193.77.134.1은 허용된 IP 범위인 193.77.134.10부터 193.77.134.50까지에 포함되지 않습니다. Account SAS IP 제한은 Storage service에서 적용되며, 요청이 허용된 범위에 없는 IP에서 시작되면 SAS가 거부되고 작업은 unauthorized가 됩니다. 따라서 193.77.134.1에서 SAS1로 Azure Storage Explorer를 사용하면 액세스할 수 없습니다. - A(자격 증명을 입력하라는 메시지 표시)는 SAS 기반 액세스에서 일반적인 동작이 아닙니다. SAS 자체가 자격 증명이며, 제약 조건을 충족하지 못하면 액세스가 거부됩니다. - C/D는 IP 제한이 충족되는 경우에만 권한이 의미가 있으므로 올바르지 않습니다.
2018년 9월 10일에 IP address가 193.77.134.50인 컴퓨터에서 net use 명령을 실행하고, share1에 연결하기 위해 SAS1을 password로 사용하면, 당신은 ______.
SAS는 유효한 시간 범위 내에 있고, IP address도 허용되며, SAS에는 read, write, list 권한이 포함된 File service가 포함되어 있지만, Windows net use command를 통한 Azure Files SMB access는 password로 SAS token을 사용하여 인증하지 않습니다. Azure file shares에 대한 SMB access에는 storage account name과 account key가 필요하거나, 구성된 경우 identity-based authentication이 필요합니다. SAS는 SMB mounting이 아니라 REST/HTTPS access에 사용됩니다. 따라서 net use에서 SAS1을 password로 사용하면 인증에 성공하지 않으며, credentials를 입력하라는 메시지가 표시되는 것으로 표현하는 것이 가장 적절합니다. 다른 옵션들이 틀린 이유는 여기서 제한 요소가 SAS permissions가 아니기 때문입니다. 문제는 net use에 대해 authentication method 자체가 지원되지 않는다는 점입니다.
참고: 이 질문은 동일한 시나리오를 제시하는 일련의 질문 중 일부입니다. 이 시리즈의 각 질문에는 명시된 목표를 충족할 수도 있는 고유한 솔루션이 포함되어 있습니다. 일부 질문 세트에는 정답이 둘 이상 있을 수 있으며, 다른 세트에는 정답이 없을 수도 있습니다. 이 섹션의 질문에 답한 후에는 해당 질문으로 돌아갈 수 없습니다. 따라서 이러한 질문은 검토 화면에 표시되지 않습니다. Windows Server 2016을 실행하는 VM1이라는 Azure virtual machine이 있습니다. 1시간 이내에 VM1의 System event log에 두 개를 초과하는 error event가 기록될 때 Azure에서 alert를 생성해야 합니다. 솔루션: VM1에서 event subscription을 생성합니다. Azure Monitor에서 alert를 생성하고 source로 VM1을 지정합니다. 이것이 목표를 충족합니까?
Yes는 오답입니다. 제안된 아키텍처에는 Windows event log에 필요한 guest log 수집 경로가 없기 때문입니다. 단순히 Azure Monitor alert를 생성하고 VM1을 source로 지정하는 것만으로는, 해당 log가 Azure Monitor Agent 또는 Log Analytics agent를 통해 수집되지 않는 한 Azure Monitor가 System event log error를 인식할 수 없습니다. 또한 event subscription은 guest OS event log 항목을 감지하는 역할을 하지 않으므로, 제시된 솔루션은 alert 목표를 달성하지 못합니다.
No가 정답인 이유는 VM1에 event subscription을 생성해도 guest operating system 내부의 Windows System event log 항목을 캡처하지 못하기 때문입니다. Azure event subscription은 Azure resource event에 사용되며, Event Viewer에 기록되는 guest OS error event를 모니터링하는 용도가 아닙니다. 요구 사항을 충족하려면 VM1의 System event log를 agent를 통해 Azure Monitor가 수집하고, 1시간 이내에 두 개를 초과하는 error event가 발생할 때 트리거되는 log alert로 평가해야 합니다.
문제 분석
핵심 개념: 이 문제는 Azure virtual machine의 guest OS event log에서 Azure alert를 생성하는 방법을 테스트합니다. 1시간 이내에 Windows System log에 두 개를 초과하는 error event가 기록될 때 alert를 발생시키려면, Azure Monitor가 agent를 통해 VM의 event log를 수집해야 하며, 일반적으로 이를 Log Analytics workspace로 전송하여 log alert가 시간 경과에 따른 개수를 평가할 수 있어야 합니다. 정답인 이유: 제안된 솔루션은 목표를 충족하지 못합니다. VM에 대한 Event Grid event subscription은 Windows guest event log를 모니터링하는 데 사용되는 메커니즘이 아니기 때문입니다. Azure event subscription은 Azure resource event를 처리하며, Windows System event log 내부에 기록되는 항목은 처리하지 않습니다. 요구 사항을 충족하려면 Azure Monitor Agent 또는 Log Analytics agent를 구성하여 Windows Event Logs를 수집한 다음, 지난 1시간 동안 VM1의 error event 수를 계산하는 query를 기반으로 log alert를 생성해야 합니다. 주요 기능 및 모범 사례: - Windows guest event log는 Azure Monitor agent와 data collection rule 또는 기존 Log Analytics agent 구성으로 모니터링합니다. - Azure Monitor log alert는 rolling 1시간 window 동안 Error level의 System log 항목 수를 계산하는 KQL query를 평가할 수 있습니다. - alert 범위를 VM1으로만 지정하는 것은, 실제 guest log 데이터가 Azure Monitor로 수집되고 있지 않다면 충분하지 않습니다. 일반적인 오해: 흔한 실수는 Azure resource event와 guest operating system event를 혼동하는 것입니다. Event Grid subscription은 resource 변경과 같은 Azure platform event에 반응할 수 있지만, VM 내부의 Windows Event Viewer log를 읽지는 않습니다. 또 다른 오해는 VM을 alert source로 선택하면 guest event log가 자동으로 노출된다고 생각하는 것이지만, agent 기반 수집 없이는 그렇지 않습니다. 시험 팁: AZ-104에서는 guest OS metric과 log는 일반적으로 agent 또는 diagnostic 구성이 필요하다는 점을 기억하세요. 요구 사항에 Windows Event Logs가 언급되면 Azure Monitor agent/Log Analytics workspace와 log alert를 떠올리세요. 요구 사항에 Azure resource lifecycle event가 언급되면 Event Grid 또는 Activity Log alert가 적절할 수 있습니다.
App1을 Azure로 이전할 계획입니다. 네트워크 보안 그룹(NSG)을 생성합니다. 사용자에게 App1에 대한 액세스를 제공하기 위한 솔루션을 권장해야 합니다. 무엇을 권장해야 합니까?
정답입니다. Internet 사용자는 웹 서버로 HTTPS 연결을 시작해야 하므로 인바운드 TCP 443을 허용해야 합니다. NSG를 웹 서버가 포함된 서브넷에 연결하면 다른 서브넷에 영향을 주지 않고 해당 티어에 규칙이 적용됩니다. NSG는 stateful이므로 응답 트래픽은 자동으로 허용되어 액세스를 위해 인바운드 허용 규칙만 필요합니다.
오답입니다. 포트 443에 대한 아웃바운드 규칙은 웹 서버에서 나가는 트래픽을 제어하며, Internet에서 들어오는 트래픽을 제어하지 않습니다. 아웃바운드 443이 허용되더라도 인바운드 허용 규칙이 없으면 기본 인바운드 Internet 거부로 인해 사용자 인바운드 연결은 여전히 차단됩니다.
오답입니다. TCP 443에 대한 인바운드 허용은 액세스를 가능하게 하지만, NSG를 모든 서브넷에 연결하는 것은 범위가 과도하며 최소 권한을 위반합니다. 443에서 수신 대기 중인 엔드포인트가 있는 경우 비웹 서브넷(앱/데이터 티어)으로의 HTTPS 트래픽을 의도치 않게 허용하여 공격 표면을 늘리고 세그먼ენტ화를 복잡하게 만들 수 있습니다.
오답입니다. 이는 두 가지 문제를 결합합니다. 아웃바운드 규칙은 인바운드 사용자 액세스를 활성화하지 않으며, 모든 서브넷에 연결하는 것은 불필요하게 광범위합니다. 기본적으로 인바운드 트래픽이 거부되므로 Internet 사용자가 웹 서버로 HTTPS 세션을 시작할 수 있게 하는 요구 사항을 충족하지 못합니다.
문제 분석
핵심 개념: 이 문제는 Azure Network Security Groups(NSG)와 NSG 보안 규칙(인바운드 vs 아웃바운드) 및 NSG 연결(서브넷 vs NIC)을 사용하여 애플리케이션을 안전하게 게시하는 방법을 평가합니다. NSG는 가상 네트워크의 Azure 리소스에 대한/로부터의 트래픽을 제어하는 stateful 패킷 필터입니다. 정답이 맞는 이유: Internet의 사용자가 HTTPS를 통해 웹 애플리케이션에 액세스하도록 하려면 웹 서버로 들어오는 TCP 포트 443 인바운드를 허용해야 합니다. 이는 source = Internet(또는 더 바람직하게는 더 좁은 source 범위)에서 destination = 웹 서버로 TCP 443을 허용하는 인바운드(수신) NSG 규칙으로 수행합니다. NSG를 웹 서버가 포함된 서브넷에 연결하면 해당 티어의 모든 VM에 규칙이 적용되며, 이는 웹 서브넷에 대한 일반적인 설계입니다. NSG는 stateful이므로 반환 트래픽은 자동으로 허용되어 응답을 위한 매칭 아웃바운드 규칙이 필요하지 않습니다. 주요 기능 / 모범 사례: - 인바운드 규칙: TCP 443 허용, Source = Internet(또는 특정 IP 범위), Destination = 웹 서브넷/VM, 우선순위를 적절히 설정. - NSG를 웹 서브넷에 연결(또는 VM별 세분화를 위해 NIC에 연결). 서브넷 연결이 더 단순하며 계층형 네트워크 설계와 일치합니다. - Azure Well-Architected Framework(Security): 최소 권한을 적용합니다. 실제 배포에서는 source를 알려진 IP로 제한하고, 앞단에 Azure Firewall/WAF(Application Gateway WAF)를 사용하며, 관리 포트를 노출하지 않는 경우가 많습니다. - 기본 NSG 규칙을 기억: Internet에서 들어오는 인바운드는 기본적으로 거부되며, VNet 트래픽은 기본적으로 허용됩니다. 흔한 오해: - 인바운드 vs 아웃바운드 혼동: 아웃바운드 443을 허용해도 Internet 사용자가 앱으로 연결을 시작할 수는 없습니다. - 과도한 범위 지정: NSG를 모든 서브넷에 연결하면 규칙이 광범위할 경우 비웹 티어가 의도치 않게 노출될 수 있습니다. 시험 팁: - “사용자가 내 앱에 액세스”라면 앱 티어(일반적으로 80/443)에 대한 인바운드 규칙을 떠올리세요. - NSG는 stateful: 인바운드 요청을 허용하면 반환 트래픽은 자동으로 허용됩니다. - 요구 사항을 충족하는 가장 좁은 범위(모든 서브넷이 아니라 웹 서브넷)에 규칙을 적용하세요.
adatum.com이라는 이름의 Azure DNS zone이 있습니다. research.adatum.com이라는 이름의 subdomain을 Azure의 다른 DNS server에 위임해야 합니다. 어떻게 해야 합니까?
정답입니다. subdomain delegation은 parent zone(adatum.com)에서 subdomain label(research) 위치에 NS record set을 생성하여 구현합니다. NS record set에는 research.adatum.com의 authoritative name server가 포함됩니다. 이는 resolver에게 research.adatum.com 아래의 모든 record에 대해 해당 server에 query하도록 지시하여, 해당 subtree에 대한 authority를 효과적으로 이전합니다.
오답입니다. PTR record는 reverse DNS lookup(IP address를 hostname으로 매핑)에 사용되며 reverse lookup zone(in-addr.arpa 또는 ip6.arpa)에 저장됩니다. research.adatum.com 같은 forward DNS namespace를 위임하지 않으며, resolver를 subdomain의 다른 authoritative name server로 보내지 않습니다.
오답입니다. SOA record에는 primary name server, responsible party, serial number, refresh/retry/expire/TTL 값과 같은 zone metadata가 포함됩니다. SOA 설정을 수정하면 zone transfer 동작이나 caching 특성에 영향을 줄 수 있지만, child domain을 다른 DNS server로 위임하는 delegation을 생성하지는 않습니다.
오답입니다. *.research라는 이름의 A record는 research.adatum.com 아래의 어떤 host든 특정 IP address로 해석하는 wildcard record이지만, authority는 adatum.com zone 내에 그대로 유지되며 subdomain을 위임하지 않습니다. delegation에는 host record가 아니라 child zone의 authoritative name server를 가리키는 NS record가 필요합니다.
문제 분석
핵심 개념: 이 문제는 Azure DNS에서 DNS delegation을 테스트합니다. subdomain을 위임한다는 것은 특정 child zone(research.adatum.com)이 parent zone(adatum.com)과는 다른 name server에서 authoritative하다고 DNS resolver에 알려주는 것을 의미합니다. DNS에서 delegation은 parent zone에 child zone의 authoritative name server를 가리키는 NS (Name Server) record로 구현됩니다. 정답이 맞는 이유: research.adatum.com을 위임하려면 adatum.com zone에 “research”라는 이름의 NS record set을 만들고, research.adatum.com을 호스팅하는 DNS server/zone의 name server FQDN(예: 다른 resource group/subscription에 있는 research.adatum.com zone에 할당된 Azure DNS name server 또는 custom DNS server)을 채웁니다. 그러면 research.adatum.com(및 그 하위)에 대한 query가 해당 name server로 referral되며, 이것이 delegation이 요구하는 동작입니다. 주요 기능 및 모범 사례: - Azure DNS에서 delegation은 parent zone의 delegation point(해당 subdomain label)에 NS record set을 생성하여 수행합니다. - 대상 DNS server가 child zone에 대해 authoritative인지 확인하고, child zone이 존재하며 필요한 record를 포함하는지 확인합니다. - Azure DNS로 위임하는 경우 일반적으로 child public DNS zone(research.adatum.com)을 먼저 생성하고, 할당된 name server를 확인한 다음, parent zone에 해당 name server를 NS record로 추가합니다. - Azure Well-Architected Framework 관점(Reliability/Operational Excellence)에서 delegation은 책임 분리(서로 다른 팀이 서로 다른 zone 관리)를 가능하게 하고 blast radius를 줄입니다. 흔한 오해: - PTR record는 reverse DNS(IP-to-name)용이며 forward lookup zone을 위임하지 않습니다. - SOA record는 zone authority parameter(serial, refresh 등)를 정의하지만 subdomain을 위임하지는 않습니다. - wildcard A record는 zone 내 name resolution에 영향을 주지만 다른 DNS server로 authority를 이전하지는 않습니다. 시험 팁: - “delegate a subdomain”은 거의 항상 “parent zone에 NS record 생성”으로 연결됩니다. - delegation에 사용되는 NS record(parent에 존재)와 zone apex에 있는 NS record set(해당 zone 자체에 대해 자동 생성됨)을 구분하세요. - Azure DNS delegation 시나리오에서는 보통 2단계로 생각합니다: child zone 생성 → 해당 name server 복사 → parent에 NS record set 생성.
HOTSPOT - 다음 전시에서 표시된 스토리지 계정이 포함된 Azure 구독이 있습니다.
그래픽에 제시된 정보를 기반으로 각 문장을 완성하는 정답 선택지를 선택하려면 드롭다운 메뉴를 사용하세요. 참고: 각 정답 선택은 1점입니다. 핫 영역:
아래 이미지에서 올바른 답(들)을 선택하세요.
이 항목은 Azure Storage 동작에 대한 실제 하위 문제가 아닙니다. 단지 '[see images below]'라고만 되어 있고, certification objective와 관련이 없는 인위적인 옵션('Pass'/'Fail')을 제공합니다. 실제로 풀이 가능한 항목은 뒤이어 나오는 hotspot 문장들이며, 이는 storage account kinds를 보여주는 exhibit를 바탕으로 답할 수 있습니다. 이 placeholder는 유효한 시험 선택지에 해당하지 않으므로, 채점되는 하위 문제로 취급해서는 안 됩니다.
______에서 premium file share를 생성할 수 있습니다.
premium file share(Azure Files premium)는 FileStorage 계정에서만 생성할 수 있습니다. 제시된 그림에서 contoso104는 Kind = FileStorage이며, 이는 premium Azure Files(SSD 기반, 프로비저닝된 IOPS/throughput)를 위한 전용 계정 유형입니다. 다른 선택지가 틀린 이유: - contoso101(StorageV2): Azure Files standard share는 지원하지만, premium file share에는 FileStorage가 필요합니다. - contoso102(Storage / GPv1): 레거시이며, 최신 premium Azure Files 기능을 지원하지 않습니다. - contoso103(BlobStorage): blob 전용이며, Azure Files share를 전혀 지원하지 않습니다. 따라서 contoso104만 해당됩니다.
______에서 Archive access tier를 사용할 수 있습니다.
Archive access tier는 blob tiering을 지원하는 표준 storage account에서 blob object에 대해 지원되는 blob access tier(Hot/Cool/Archive)입니다. 다음에서 지원됩니다: - StorageV2 (contoso101): GPv2는 Archive를 포함한 blob access tier를 지원합니다. - BlobStorage (contoso103): Archive를 포함한 blob tier를 지원합니다(레거시 blob-only account). 다른 선택지가 틀린 이유: - contoso102 (Storage / GPv1): Archive를 포함하는 전체 blob access tiering 모델을 지원하지 않습니다. - contoso104 (FileStorage): premium Azure Files에 사용됩니다. Archive는 Azure Files tier가 아니며 file share에는 적용되지 않습니다. 따라서 Archive는 contoso101 또는 contoso103에서만 사용할 수 있습니다.
다른 모의고사
Practice Test #1
Practice Test #2
Practice Test #3
Practice Test #4
Practice Test #5
Practice Test #6
Practice Test #7
Practice Test #9
지금 학습 시작하기
Cloud Pass를 다운로드하고 모든 Microsoft AZ-104 기출 문제를 풀어보세요.
이동 중에도 모든 문제를 풀고 싶으신가요?
앱 받기
Cloud Pass를 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.