본문 바로가기
인공지능,프로그래밍/MS Azure

AZ-104 시험 대비 문제 we-part2

AI 마을1 2025. 4. 22. 17:48

문제 111

Azure 구독에 다음과 같은 Azure 파일 공유가 있습니다.

  • share1 (storageaccount1에 호스팅, West US 위치)
  • share2 (storageaccount1에 호스팅, West US 위치)

다음과 같은 온-프레미스 서버가 있습니다.

  • server1 (D:\folder1, E:\folder2)
  • server2 (D:\data)

sync1이라는 Storage Sync Service와 group1이라는 Azure File Sync Group을 만듭니다. group1은 share1을 클라우드 엔드포인트로 사용합니다. server1과 server2를 sync1에 등록합니다. server1의 D:\folder1을 group1의 서버 엔드포인트로 추가합니다. 각각의 다음 설명이 참인지 거짓인지 선택하세요.

  • share2는 group1의 클라우드 엔드포인트로 추가될 수 있습니다.
  • server2의 D:\data는 group1의 서버 엔드포인트로 추가될 수 있습니다.
  • server1의 E:\folder2는 group1의 서버 엔드포인트로 추가될 수 있습니다.

 

해설:

 

Azure File Sync의 구조에 따르면 다음이 중요합니다:

  1. Sync Group 내에서는 단일 클라우드 엔드포인트만 존재합니다. 즉, 하나의 Sync Group은 하나의 Azure 파일 공유만 클라우드 엔드포인트로 가질 수 있습니다.
  2. 서버 엔드포인트는 Sync Group 내의 클라우드 엔드포인트와 동기화되는 대상 서버의 로컬 폴더입니다.
  3. 하나의 서버(Sync Agent가 등록된) 내에서, Sync Group별로 최대 서버 엔드포인트 수에는 제한이 있지만, 원칙적으로 동일한 Sync Group 내에 여러 서버 엔드포인트(서버 및 경로)를 추가할 수 있습니다.

따라서 이번 상황을 각 항목별로 판단하면,

  • share2는 group1의 클라우드 엔드포인트로 추가될 수 있는가?
    group1은 이미 share1을 클라우드 엔드포인트로 지정했으므로, 단일 Sync Group 내에서 두 개의 클라우드 엔드포인트를 가질 수 없습니다.
    → 이는 거짓입니다.
  • server2의 D:\data는 group1의 서버 엔드포인트로 추가될 수 있는가?
    server2가 이미 sync1에 등록되어 있고, group1의 클라우드 엔드포인트가 share1이므로, server2의 D:\data를 해당 Sync Group에 서버 엔드포인트로 추가하는 것은 가능합니다.
    → 참입니다.
  • server1의 E:\folder2는 group1의 서버 엔드포인트로 추가될 수 있는가?
    server1이 sync1에 등록되어 있고, server1의 D:\folder1이 group1에 서버 엔드포인트로 이미 추가되어 있어도, 동일 서버 내에서 여러 경로를 서버 엔드포인트로 추가할 수 있습니다. 그러므로 E:\folder2 역시 서버 엔드포인트로 추가 가능합니다.
    → 참입니다.

이 결론은 Azure 공식 문서에 명시된 Azure File Sync Sync Group 및 Storage Sync Service 구성 제한 사항에 부합합니다.

참고: Sync Group 하나에는 반드시 하나의 Azure 파일 공유(클라우드 엔드포인트)만 존재하며, 여러 서버 및 여러 경로의 서버 엔드포인트를 등록할 수 있습니다.

반면, 동일 Sync Group 내에서는 여러 서버와 여러 로컬 경로(서버 엔드포인트)를 추가할 수 있습니다. server2의 D:\data 경로를 group1의 서버 엔드포인트로 추가하는 것과, server1의 E:\folder2를 서버 엔드포인트로 추가하는 것은 모두 가능합니다. 따라서 이 두 설명은 참입니다.

즉,

  • share2는 group1의 클라우드 엔드포인트로 추가될 수 없다 → 거짓
  • server2의 D:\data는 group1의 서버 엔드포인트로 추가될 수 있다 → 참
  • server1의 E:\folder2는 group1의 서버 엔드포인트로 추가될 수 있다 → 참

이 결과는 Azure 공식 문서(available references)와 Azure File Sync 설계 가이드에 근거한 정확한 정보입니다.

추가적으로, Azure File Sync를 통해 여러 서버의 데이터가 단일 Azure 파일 공유와 동기화될 때, Sync Group을 통해 중앙 집중식 관리를 하며, 이 구조가 효율적입니다.

필요시 Microsoft Azure 공식 문서를 참조하시면 더욱 상세한 내용을 확인하실 수 있습니다.

  • Azure Files: 클라우드에서 접근 가능한 파일 공유를 제공하는 Azure 서비스입니다. 마치 네트워크 드라이브와 같습니다.
  • 온-프레미스 (On-Premise): 클라우드 환경이 아닌 자체 데이터 센터나 서버실에 있는 환경을 의미합니다.
  • Storage Sync Service: 온-프레미스 서버와 Azure 파일 공유 간의 파일 동기화를 관리하는 Azure 서비스입니다. 마치 파일 동기화 서비스의 중앙 관리자 역할과 같습니다.
  • Azure File Sync Group: 동기화할 서버 엔드포인트와 클라우드 엔드포인트의 관계를 정의하는 그룹입니다.
  • 클라우드 엔드포인트 (Cloud Endpoint): Azure 파일 공유를 동기화 그룹에 연결한 것입니다.
  • 서버 엔드포인트 (Server Endpoint): 온-프레미스 서버의 폴더를 동기화 그룹에 연결한 것입니다.
  • 등록 (Register): 온-프레미스 서버를 Storage Sync Service에 연결하는 과정입니다.
  • 동기화 (Synchronization): 파일이나 데이터를 여러 위치에서 최신 상태로 유지하는 과정입니다.

정답:

  • share2는 group1의 클라우드 엔드포인트로 추가될 수 있습니까? 아니요. (하나의 동기화 그룹에는 하나의 클라우드 엔드포인트만 있을 수 있습니다.)
  • server2의 D:\data는 group1의 서버 엔드포인트로 추가될 수 있습니까? 예. (하나의 동기화 그룹에는 여러 서버 엔드포인트를 추가할 수 있습니다.)
  • server1의 E:\folder2는 group1의 서버 엔드포인트로 추가될 수 있습니까? 아니요. (하나의 서버에서는 동일한 동기화 그룹에 하나의 서버 엔드포인트만 추가할 수 있습니다. D:\folder1이 이미 추가되어 있습니다.)

 

문제 112

Azure File Sync 그룹에 다음과 같은 엔드포인트가 있습니다.

  • endpoint1: 클라우드 엔드포인트
  • endpoint2: 서버 엔드포인트
  • endpoint3: 서버 엔드포인트 (클라우드 계층화 활성화)

endpoint1에 file1을 추가하고 endpoint2에 file2를 추가합니다. 파일을 추가한 후 24시간 이내에 file1과 file2는 어떤 엔드포인트에서 사용할 수 있을까요?

보기 (file1):

A. endpoint1 만 B. endpoint3 만 C. endpoint2 및 endpoint3 D. endpoint1, endpoint2 및 endpoint3

보기 (file2):

A. endpoint2 만 B. endpoint3 만 C. endpoint2 및 endpoint3 만 D. endpoint1, endpoint2 및 endpoint3

해설:

 

Azure File Sync 환경에서 다음 사항을 고려해야 합니다.

  • 클라우드 엔드포인트 (endpoint1): Azure 파일 공유의 클라우드 위치입니다.
  • 서버 엔드포인트 (endpoint2, endpoint3): 온프레미스 서버의 로컬 저장소 위치이며, endpoint3은 클라우드 계층화(Cloud Tiering) 기능이 활성화된 서버 엔드포인트입니다.

file1 (endpoint1에 추가한 파일)

  • 클라우드 엔드포인트에 직접 추가된 파일은 즉시 클라우드에 존재합니다.
  • 서버 엔드포인트로는 동기화 프로세스에 따라 점차 내려받아집니다.
  • 클라우드 계층화 활성화된 endpoint3의 경우, 자주 접근하지 않는 파일은 클라우드에만 보관되고 로컬에는 일부만 유지되지만, 새로 추가된 파일은 로컬에도 동기화됩니다.
  • endpoint2 (클라우드 계층화 비활성)도 동기화를 통해 파일을 내려받습니다.

따라서 24시간 이내에는 file1이

  • endpoint1(클라우드)
  • endpoint2(서버)
  • endpoint3(서버, 클라우드 계층화)
    모두에서 사용할 수 있습니다.

file2 (endpoint2에 추가한 파일)

  • 서버 엔드포인트에 추가된 파일은 클라우드로 업로드되어 클라우드 엔드포인트에 동기화됩니다.
  • 클라우드 계층화 활성화된 endpoint3에도 동기화되어 접근 가능해집니다.
  • 즉, endpoint2, endpoint3, endpoint1 모두에서 파일을 사용할 수 있습니다.

정답

파일 정답 보기
file1 D) endpoint1, endpoint2 및 endpoint3
file2 D) endpoint1, endpoint2 및 endpoint3

필요 시 더 자세한 설명이나 추가 질문도 환영합니다!

  • 클라우드 계층화 (Cloud Tiering): 자주 사용되지 않는 파일을 클라우드 엔드포인트로 이동시켜 서버의 로컬 공간을 절약하는 Azure File Sync 기능입니다.
  • 검색 작업 (Detection Job): 클라우드 엔드포인트에서 변경된 파일을 검색하는 주기적인 프로세스입니다. (기본 24시간마다 실행)
  • 자동 동기화 (Automatic Synchronization): 서버 엔드포인트에서 변경된 파일은 즉시 다른 엔드포인트와 동기화됩니다.

정답 (file1): A (file1은 클라우드 엔드포인트에 추가되었으므로, 검색 작업이 실행되기 전까지는 클라우드 엔드포인트에서만 사용할 수 있습니다.)

정답 (file2): D (file2는 서버 엔드포인트에 추가되었으므로, 즉시 클라우드 엔드포인트와 다른 서버 엔드포인트로 동기화됩니다. 따라서 24시간 이내에 모든 엔드포인트에서 사용할 수 있습니다.)

 

 

문제 113

Azure 구독에 10개의 가상 머신이 있습니다. 가상 네트워크는 별도의 리소스 그룹에 호스팅되어 있으며, 다른 관리자가 구독에 여러 네트워크 보안 그룹(NSG)을 만들 계획입니다. NSG가 생성될 때 가상 네트워크 간의 TCP 포트 8080을 자동으로 차단해야 합니다. 리소스 공급자 블레이드에서 microsoft.classicnetwork 공급자를 등록 취소하는 솔루션을 제공합니다. 이 솔루션이 목표를 충족합니까?

해설:

 

Azure 구독에서 Microsoft.ClassicNetwork 공급자 등록 취소가 TCP 포트 8080 자동 차단에 미치는 영향

제공된 솔루션은 목표를 달성하지 못합니다. 아래에서 상세한 분석을 제공합니다.

핵심 분석 요약

  1. Microsoft.ClassicNetwork의 역할:
    • 이 공급자는 클래식 배포 모델(ASM) 의 가상 네트워크를 관리합니다1235.
    • ARM(Azure Resource Manager) 기반 리소스에는 영향을 주지 않습니다.
  2. 문제의 컨텍스트:
    • 가상 네트워크가 별도의 리소스 그룹에 호스팅되어 있다는 점에서 ARM 환경임을 확인할 수 있습니다235.
    • NSG(네트워크 보안 그룹)는 ARM 기반 리소스이므로, Microsoft.ClassicNetwork 등록 취소와 무관합니다.
  3. 솔루션의 문제점:
    • Microsoft.ClassicNetwork 등록 취소는 클래식 네트워크 리소스 생성만 차단하며, ARM 기반 NSG 생성에는 영향을 미치지 않습니다235.
    • 따라서 TCP 포트 8080 차단 규칙 자동화와 직접적인 연관성이 없습니다.

권장 해결 방안

목표를 달성하려면 다음 방법을 사용해야 합니다:

방법 설명
Azure Policy NSG 생성 시 TCP 8080 차단 규칙을 강제하는 정책을 정의합니다.
NSG 기본 규칙 활용 모든 NSG에 적용되는 기본 규칙을 설정하여 포트 8080을 차단합니다.
Azure Firewall 네트워크 계층에서 포트 8080 트래픽을 차단하는 방화벽 규칙을 구성합니다.
 

추가 참고 사항

  • ARM vs. 클래식 리소스: ARM은 최신 Azure 배포 모델이며, 클래식 리소스는 점차 지원이 중단되고 있습니다12.
  • 리소스 공급자 관리: Microsoft.Network 공급자가 등록되어 있어야 ARM 기반 NSG를 생성할 수 있습니다1.
 
  • 네트워크 보안 그룹 (Network Security Group, NSG): Azure 리소스에 대한 인바운드 및 아웃바운드 네트워크 트래픽을 제어하는 방화벽 역할을 하는 서비스입니다. 마치 건물의 경비 시스템과 같습니다.
  • TCP (Transmission Control Protocol) 포트 8080: 특정 애플리케이션이나 서비스가 네트워크 통신을 위해 사용하는 논리적인 통로입니다.
  • 리소스 공급자 (Resource Provider): 특정 Azure 리소스 유형을 만들고 관리하는 서비스를 제공합니다. microsoft.classicnetwork는 이전 Azure 배포 모델에 사용되던 리소스 공급자입니다.
  • 등록 취소 (Unregister): 리소스 공급자를 구독에서 제거하는 것입니다.
  • Azure Policy: Azure 리소스에 대한 규칙을 정의하고 적용하는 서비스입니다. 사용자 정의 정책을 통해 특정 조건이 발생하면 자동으로 특정 작업을 수행하도록 설정할 수 있습니다.

정답: 아니요. (microsoft.classicnetwork 공급자를 등록 취소하는 것은 새로운 NSG 생성 시 TCP 포트 8080을 자동으로 차단하는 것과 관련이 없습니다. 이 목표를 달성하려면 Azure Policy를 사용하여 NSG 생성 시 특정 규칙을 자동으로 추가하도록 구성해야 합니다.)

 

문제 114

contoso.com이라는 프로덕션 Azure Active Directory 테넌트가 있습니다.

개발 Azure Active Directory 테넌트를 배포한 다음 개발 테넌트에 여러 사용자 지정 관리 역할을 만듭니다.

이러한 역할을 프로덕션 테넌트에 복사해야 합니다. 가장 먼저 무엇을 해야 할까요?

보기:

A. 프로덕션 테넌트에서 새 사용자 지정 역할 만들기

B. 프로덕션 테넌트에서 관리 단위 만들기

C. 개발 테넌트에서 사용자 지정 역할을 JSON으로 내보내기

D. 복사하기 위해 개발 테넌트에서 백업 수행

 

해설:

정답은 C. 개발 테넌트에서 사용자 지정 역할을 JSON으로 내보내기입니다.

  • 사용자 지정 역할(Azure Custom Role)은 JSON 형식으로 정의되어 있습니다.
  • 역할을 한 테넌트에서 다른 테넌트로 복사하려면, 먼저 개발 테넌트에서 해당 역할의 정의를 JSON 파일로 내보내야 합니다12.
  • 내보낸 JSON 파일을 프로덕션 테넌트에서 불러와 동일한 역할을 생성할 수 있습니다.
  • Microsoft 공식 문서에서도 **"Save each custom role that you will need in the target directory as a separate JSON file."**라고 안내하고 있습니다1.

다른 보기 해설

  • A. 프로덕션 테넌트에서 새 사용자 지정 역할 만들기
    → 역할 정의(JSON)를 준비하지 않고 바로 생성할 수 없습니다.
  • B. 프로덕션 테넌트에서 관리 단위 만들기
    → 관리 단위는 역할 복사와 직접 관련이 없습니다.
  • D. 복사하기 위해 개발 테넌트에서 백업 수행
    → "백업"이라는 용어는 역할 정의 내보내기와는 다릅니다.

따라서, **가장 먼저 해야 할 일은 개발 테넌트에서 사용자 지정 역할을 JSON으로 내보내는 것(C)**입니다.
이후에 이 JSON 파일을 프로덕션 테넌트에서 사용해 동일한 역할을 생성하면 됩니다12.

 

  • 프로덕션 테넌트 (Production Tenant): 실제 사용자들이 사용하는 운영 환경의 Azure AD 테넌트입니다.
  • 개발 테넌트 (Development Tenant): 개발 및 테스트 목적으로 사용하는 별도의 Azure AD 테넌트입니다.
  • 사용자 지정 관리 역할 (Custom Administrative Roles): Azure 리소스에 대한 세분화된 권한을 정의하기 위해 사용자가 직접 만드는 역할입니다.
  • JSON (JavaScript Object Notation): 데이터를 텍스트 기반으로 표현하는 표준 형식입니다.
  • 관리 단위 (Administrative Unit): Azure AD 개체(사용자, 그룹, 장치)를 논리적으로 그룹화하여 관리 권한의 범위를 제한하는 데 사용됩니다.
  • 백업 (Backup): 데이터나 시스템 설정을 저장하여 나중에 복원할 수 있도록 하는 것입니다.

정답: C (개발 테넌트에서 사용자 지정 역할을 JSON 파일로 내보낸 다음, 프로덕션 테넌트에서 해당 JSON 파일을 사용하여 역할을 다시 만드는 것이 사용자 지정 역할을 테넌트 간에 이동하는 일반적인 방법입니다.)

 

문제 115

Network Watcher를 사용하여 다음 작업을 수행하려고 합니다.

  1. 네트워크 패킷이 Azure 가상 머신에 도달하는 것을 막는 보안 규칙 식별
  2. Azure 가상 머신에서 외부 호스트로의 아웃바운드 연결 유효성 검사

각 작업에 사용할 기능을 선택하세요.

보기:

  • Traffic Analytics
  • Security Group View
  • Packet Capture
  • Next Hop
  • IP Flow Verify
  • Connection Troubleshoot

해설:

아래는 각 작업에 적합한 Network Watcher 기능입니다.

작업 내용 사용할 기능
네트워크 패킷이 Azure 가상 머신에 도달하는 것을 막는 보안 규칙 식별 IP Flow Verify
Azure 가상 머신에서 외부 호스트로의 아웃바운드 연결 유효성 검사 Connection Troubleshoot
 

근거 및 설명

  • IP Flow Verify:
    이 기능은 특정 트래픽(예: 특정 IP, 포트, 프로토콜)이 VM에 도달할 수 있는지, 그리고 만약 차단된다면 어떤 NSG 보안 규칙이 트래픽을 차단하는지를 명확히 보여줍니다. 결과로 허용/거부 여부와 적용된 규칙명을 제공합니다3467.
  • Connection Troubleshoot:
    이 기능은 VM에서 외부 호스트(다른 VM, IP, FQDN 등)로의 연결이 실제로 가능한지 테스트합니다. 연결이 실패하면 NSG, 라우팅, VM 방화벽 등 다양한 원인을 분석하여 알려줍니다. 즉, 아웃바운드 연결의 유효성을 종합적으로 점검할 수 있습니다589.

요약

  • 보안 규칙에 의해 트래픽이 차단되는 원인 식별:
    → IP Flow Verify
  • VM에서 외부로의 연결 유효성 검사:
    → Connection Troubleshoot
 

 

  • Traffic Analytics: Azure 네트워크 트래픽의 흐름에 대한 인사이트를 제공하는 Network Watcher 기능입니다.
  • Security Group View: 가상 머신 또는 서브넷에 적용된 네트워크 보안 그룹과 그 규칙을 보여주는 Network Watcher 기능입니다.
  • Packet Capture: 가상 머신을 오가는 네트워크 트래픽을 캡처하여 분석할 수 있도록 하는 Network Watcher 기능입니다.
  • Next Hop: 가상 머신에서 특정 대상 IP 주소로 가는 트래픽이 어떤 다음 홉(라우터)으로 전달되는지 보여주는 Network Watcher 기능입니다.
  • IP Flow Verify: 특정 IP 주소와 포트 간의 트래픽이 네트워크 보안 그룹 규칙에 의해 허용되는지 또는 거부되는지 확인하는 Network Watcher 기능입니다.
  • Connection Troubleshoot: 특정 시점에 두 Azure 리소스 간의 연결 문제를 진단하는 Network Watcher 기능입니다.
  • 인바운드 (Inbound): 외부에서 Azure 리소스로 들어오는 트래픽입니다.
  • 아웃바운드 (Outbound): Azure 리소스에서 외부로 나가는 트래픽입니다.

정답:

  • 작업 1: IP Flow Verify (패킷이 거부되는 보안 규칙을 정확히 식별할 수 있습니다.)
  • 작업 2: Connection Troubleshoot (가상 머신에서 외부 호스트로의 연결을 테스트하고 결과를 확인할 수 있습니다.)

 

문제 116

app1이라는 애플리케이션을 두 개의 Azure 가상 머신(vm1, vm2)에 배포했습니다.

app1에 대한 Azure 가용성 집합을 구현하려고 합니다.

솔루션은 vm1과 vm2를 호스팅하는 서버의 계획된 유지 관리 중에도 app1을 사용할 수 있도록 해야 합니다.

가용성 집합에 무엇을 포함해야 할까요?

보기:

A. 단일 업데이트 도메인

B. 단일 장애 도메인

C. 두 개의 업데이트 도메인

D. 두 개의 장애 도메인

 

 

해설:

 

정답은 C. 두 개의 업데이트 도메인입니다.

핵심 분석

가용성 집합에서 **업데이트 도메인(Update Domain)**은 계획된 유지 관리 중 VM 재시작 순서를 제어합니다.

  • Azure는 유지 관리 시 한 번에 하나의 업데이트 도메인만 재시작하며, 다음 업데이트 도메인으로 넘어가기 전에 30분간 복구 시간을 가집니다.
  • 두 개의 업데이트 도메인을 구성하면, vm1과 vm2가 서로 다른 업데이트 도메인에 배치되어 동시에 유지 관리되지 않습니다.
  • 이로 인해 app1은 한 VM이 유지 관리 중이더라도 다른 VM에서 계속 서비스할 수 있습니다.
보기 이유
A. 단일 업데이트 도메인 두 VM이 동일한 업데이트 도메인에 배치되어 유지 관리 시 동시에 중단됩니다.
B. 단일 장애 도메인 장애 도메인(Fault Domain)은 물리적 랙 장애를 격리하는 것이 목적이며,
계획된 유지 관리와 무관합니다.
D. 두 개의 장애 도메인 장애 도메인 분리는 하드웨어 장애에 대비하지만,
유지 관리 시 모든 장애 도메인의 VM이 동시에 영향을 받을 수 있습니다.
 

추가 참고 사항

  • 가용성 집합 생성 시 업데이트 도메인 수는 최대 20개까지 설정 가능하며, VM 수 ≥ 업데이트 도메인 수가 되도록 구성해야 합니다.
  • 예를 들어, 5개의 VM을 5개의 업데이트 도메인에 배치하면 각 VM이 별도의 도메인에 할당되어 유지 관리 영향이 최소화됩니다.

 

  • Azure 가용성 집합 (Azure Availability Set): Azure 데이터 센터 내에서 가상 머신을 논리적으로 그룹화하여 하드웨어 오류 및 계획된 유지 관리로부터 애플리케이션을 보호하는 서비스입니다. 마치 건물의 여러 층에 서버를 분산시켜서 한 층에 문제가 생겨도 다른 층에서 서비스를 계속할 수 있도록 하는 것과 같습니다.
  • 업데이트 도메인 (Update Domain): 계획된 유지 관리 이벤트(예: 시스템 업데이트) 중에 동시에 재부팅될 수 있는 가상 머신의 그룹입니다.
  • 장애 도메인 (Fault Domain): 공유 전원 및 네트워크 스위치를 공유하는 가상 머신의 그룹입니다. 예기치 않은 하드웨어 오류가 발생했을 때 동시에 영향을 받을 수 있습니다.
  • 계획된 유지 관리 (Planned Maintenance): Azure 플랫폼 업데이트와 같이 미리 예정된 시스템 유지 관리입니다.
  • 예기치 않은 유지 관리 (Unplanned Maintenance): 하드웨어 오류 등으로 인해 예기치 않게 발생하는 시스템 유지 관리입니다.

정답: C (계획된 유지 관리 중에도 애플리케이션 가용성을 보장하려면 가상 머신을 두 개 이상의 업데이트 도메인에 배치해야 합니다. 이렇게 하면 업데이트가 한 번에 모든 VM에 적용되지 않아 최소한 하나의 VM은 계속 실행됩니다.)

 

 

문제 117

Azure 구독에 다음과 같은 공용 Load Balancer가 있습니다.

  • lb1 (Basic SKU)
  • lb2 (Standard SKU)

6개의 가상 머신을 만들고 각 Load Balancer를 사용하여 3개의 가상 머신에 대한 요청을 부하 분산하려고 합니다. 계획된 솔루션을 위해 가상 머신을 어떻게 만들어야 할까요?

  • lb1을 사용하여 부하 분산할 가상 머신은 반드시 ______
  • lb2를 사용하여 부하 분산할 가상 머신은 반드시 ______

보기:

  • 동일한 리소스 그룹에 생성되어야 합니다.
  • 동일한 운영 체제를 실행해야 합니다.
  • 동일한 가상 네트워크에 연결되어야 합니다.
  • 동일한 가용성 집합 또는 가상 머신 확장 집합에 생성되어야 합니다.

해설:

아래는 각 Load Balancer SKU에 따라 가상 머신을 어떻게 만들어야 하는지에 대한 정답입니다.

lb1(기본 SKU)로 부하 분산할 가상 머신은 반드시
동일한 가용성 집합 또는 가상 머신 확장 집합에 생성되어야 합니다.

  • Basic Load Balancer의 백엔드 풀은 반드시 동일한 가용성 집합(Availability Set) 또는 동일한 VM 확장 집합(Scale Set) 내의 VM만 포함할 수 있습니다15.

lb2(표준 SKU)로 부하 분산할 가상 머신은 반드시
동일한 가상 네트워크에 연결되어야 합니다.

  • Standard Load Balancer는 동일한 가상 네트워크(VNet) 내에 있는 VM 또는 VM 확장 집합이면 가용성 집합과 무관하게 백엔드 풀에 추가할 수 있습니다126.

요약

Load Balancer 가상 머신 조건
lb1 (Basic) 동일한 가용성 집합 또는 가상 머신 확장 집합에 생성되어야 함
lb2 (Standard) 동일한 가상 네트워크에 연결되어야 함
 
 
  • 부하 분산 장치 (Load Balancer): 들어오는 네트워크 트래픽을 여러 서버에 분산시켜서 서비스의 가용성과 응답성을 높이는 Azure 서비스입니다.
  • SKU (Stock Keeping Unit): Azure 서비스의 특정 계층 또는 버전을 나타냅니다. Basic과 Standard는 Load Balancer의 기능과 확장성 수준을 나타냅니다.
  • 가용성 집합 (Availability Set): 하드웨어 오류 및 계획된 유지 관리로부터 애플리케이션을 보호하기 위해 가상 머신을 논리적으로 그룹화하는 것입니다.
  • 가상 머신 확장 집합 (Virtual Machine Scale Set): 동일한 구성에서 여러 개의 가상 머신을 자동으로 배포하고 관리할 수 있도록 하는 서비스입니다. 트래픽 변화에 따라 자동으로 VM 수를 늘리거나 줄일 수 있습니다.
  • 기본 Load Balancer (Basic Load Balancer): 기본적인 부하 분산 기능을 제공하며, 단일 가용성 집합 또는 가상 머신 확장 집합 내의 VM만 지원합니다.
  • 표준 Load Balancer (Standard Load Balancer): 고급 기능(예: 영역 간 부하 분산, 아웃바운드 SNAT 제어)을 제공하며, 단일 가상 네트워크 내의 모든 VM을 지원합니다.

정답:

  • lb1을 사용하여 부하 분산할 가상 머신은 반드시 동일한 가용성 집합 또는 가상 머신 확장 집합에 생성되어야 합니다. (Basic Load Balancer의 제약 사항)
  • lb2를 사용하여 부하 분산할 가상 머신은 반드시 동일한 가상 네트워크에 연결되어야 합니다. (Standard Load Balancer는 단일 가상 네트워크 내의 VM을 지원합니다.)

 

문제 118

East US Azure 지역에 호스팅되는 vnet1이라는 가상 네트워크를 관리합니다.

vnet1에는 Windows Server를 실행하는 vm1과 vm2라는 두 개의 가상 머신이 있습니다.

3시간 동안 vm1에서 vm2로 가는 모든 네트워크 트래픽을 검사해야 합니다.

Azure Network Watcher에서 패킷 캡처를 만드는 솔루션을 제공합니다. 이 솔루션이 목표를 충족합니까?

 

해설:

Azure Network Watcher에서 패킷 캡처를 만드는 솔루션은 목표를 충족합니다.

  • Packet Capture 기능을 사용하면 특정 가상 머신(vm1)에서 지정한 시간(예: 3시간) 동안 들어오고 나가는 모든 네트워크 트래픽을 캡처할 수 있습니다.
  • 캡처 세션은 **최대 시간 제한(Time limit)**을 설정할 수 있으며, 기본값은 18,000초(5시간)로 3시간(10,800초)도 충분히 지원됩니다.
  • 필터를 통해 vm1에서 vm2로 가는 트래픽만 캡처하도록 설정할 수 있습니다(예: 대상 IP, 포트 등으로 필터 지정).
  • 캡처된 데이터는 분석을 위해 Azure Storage 또는 로컬 파일로 저장할 수 있습니다.

따라서, Network Watcher의 패킷 캡처 기능을 활용하면 vm1에서 vm2로 가는 모든 네트워크 트래픽을 3시간 동안 검사할 수 있습니다

  • Azure Network Watcher: Azure 네트워크를 모니터링하고 진단하는 서비스입니다.
  • 패킷 캡처 (Packet Capture): 네트워크를 통해 전송되는 데이터를 기록하는 프로세스입니다. 네트워크 문제를 진단하거나 보안 분석을 위해 사용됩니다.
  • 가상 네트워크 (Virtual Network): Azure에서 생성하는 사설 네트워크입니다.

정답: 예. (Network Watcher의 패킷 캡처 기능을 사용하면 지정된 기간 동안 두 가상 머신 간의 모든 네트워크 트래픽을 기록하고 분석할 수 있습니다.)

 

 

문제 119

여러 가지 다른 이미지를 사용하여 여러 VM을 만드는 스크립트가 있습니다.

첫 번째 VM을 만드는 명령을 실행할 때 VM이 생성되는 동안 스크립트가 차단되는 것을 원하지 않고,

즉시 다음 명령으로 진행되기를 원합니다. 이를 수행하는 가장 좋은 방법은 무엇일까요?

보기:

A. 백그라운드에서 프로세스를 실행하기 위해 앰퍼샌드(&) 사용

B. 만들기 명령에 --no-wait 인수 추가

C. 차단을 피하기 위해 만들기 명령에 --async 인수 추가

 

해설:

가장 좋은 방법은 B. 만들기 명령에 --no-wait 인수 추가입니다.

  • Azure CLI 또는 PowerShell에서 VM을 생성할 때 기본적으로 명령이 완료될 때까지(즉, VM이 완전히 만들어질 때까지) 스크립트 실행이 차단됩니다.
  • --no-wait 인수를 추가하면, VM 생성 요청만 전송하고 명령 실행이 즉시 반환되어 스크립트가 다음 명령으로 바로 진행됩니다27.
  • 여러 VM을 반복문 등으로 만들 때 각 명령에 --no-wait를 붙이면, VM 생성이 병렬적으로 진행되어 전체 소요 시간이 단축됩니다.
  • A(앰퍼샌드 & 사용): 셸 스크립트에서는 백그라운드 실행이 가능하지만, Azure CLI 자체의 비동기 처리는 --no-wait가 공식적이고 권장되는 방법입니다.
  • C(--async 인수): Azure VM 생성 명령에는 --async 옵션이 없습니다.

따라서,
여러 VM을 빠르게 만들고 스크립트가 차단되지 않으려면 각 VM 생성 명령에 --no-wait를 추가하세요.

앰퍼샌드(&)를 사용하면 스크립트가 차단되지 않나요?

앰퍼샌드(&)를 사용하면 스크립트가 해당 명령에서 차단되지 않습니다.

  • 리눅스/유닉스 셸(Bash 등)에서 명령어 끝에 **&**를 붙이면, 해당 명령이 백그라운드 프로세스로 실행되어 스크립트가 즉시 다음 줄로 진행됩니다.
  • 예시:위와 같이 실행하면, VM 생성 명령이 백그라운드에서 실행되고 스크립트는 다음 명령으로 넘어갑니다.
  • az vm create ... &

다만, Azure CLI에서 공식적으로 비동기 처리를 지원하는 방법은 --no-wait 옵션을 사용하는 것입니다.

  • --no-wait는 명령이 Azure에 요청만 보내고 바로 반환되도록 하여, CLI 사용 시 권장되는 방식입니다.
  • &는 셸의 기능이고, --no-wait는 Azure CLI의 기능입니다. 두 방법 모두 스크립트 차단을 방지할 수 있지만, Azure CLI에서는 --no-wait가 더 명확하고 안전합니다.
  • 스크립트 (Script): 일련의 명령어를 담고 있는 파일입니다. 자동화된 작업을 수행하는 데 사용됩니다.
  • Azure CLI: Azure 서비스를 관리하기 위한 명령줄 인터페이스입니다.
  • 가상 머신 (Virtual Machine): 클라우드에서 실행되는 가상의 컴퓨터입니다.
  • 차단 (Blocking): 특정 작업이 완료될 때까지 다음 명령어가 실행되지 않고 기다리는 상태입니다.
  • 비동기 (Asynchronous): 특정 작업이 완료되기를 기다리지 않고 다음 명령어를 즉시 실행하는 방식입니다.
  • --no-wait: Azure CLI 명령에서 작업을 백그라운드에서 시작하고 완료를 기다리지 않고 즉시 제어를 반환하도록 하는 인수입니다.
  • --async: 일부 프로그래밍 환경에서 비동기 작업을 시작하는 데 사용되는 인수입니다.
  • 앰퍼샌드 (&): Unix/Linux 쉘 스크립트에서 명령을 백그라운드에서 실행하는 데 사용되는 기호입니다.

정답: B (--no-wait 인수를 만들기 명령에 추가하면 VM 생성이 백그라운드에서 진행되는 동안 스크립트가 즉시 다음 명령으로 진행됩니다.)

 

문제 120

Azure 구독이 있습니다.

app1이라는 앱을 지원하기 위해 Azure Kubernetes Service (AKS) 클러스터를 배포하려고 합니다.

온-프레미스 클라이언트는 AKS 클러스터의 포드 IP 주소를 사용하여 app1에 연결합니다.

app1을 지원할 네트워크 유형을 선택해야 합니다. 무엇을 선택해야 할까요?

보기:

A. Hybrid Connection 엔드포인트

B. Azure Private Link

C. Kubenet

D. Azure Container Networking Interface (CNI)

 

해설:

온-프레미스 클라이언트가 AKS 클러스터의 포드 IP 주소를 직접 사용하여 app1에 연결해야 한다면,
**Azure Container Networking Interface (CNI)**를 선택해야 합니다.

근거

  • Azure CNI를 사용하면, 각 포드가 Azure 가상 네트워크(VNet) 서브넷에서 직접 IP 주소를 할당받아 온-프레미스 네트워크 등 외부에서 포드 IP로 직접 접근할 수 있습니다.
  • 반면 Kubenet은 포드에 별도의 논리적 주소를 할당하고, 외부에서 포드 IP로 직접 접근이 불가능하며, 트래픽이 노드 IP를 통해 NAT됩니다.
  • Microsoft 공식 문서에서도 외부 리소스(온-프레미스 등)에서 포드에 직접 접근해야 하는 경우 Azure CNI를 사용하라고 명시하고 있습니다.

정답

D. Azure Container Networking Interface (CNI)

"With Azure Container Networking Interface (CNI), every pod gets an IP address from the subnet and can be accessed directly."
— Microsoft Docs

 

  • Azure Kubernetes Service (AKS): 컨테이너화된 애플리케이션을 쉽게 배포, 관리 및 확장할 수 있도록 해주는 관리형 Kubernetes 서비스입니다. 마치 컨테이너들을 위한 오케스트라 지휘자와 같습니다.
  • 포드 (Pod): Kubernetes의 가장 작은 배포 단위이며, 하나 이상의 컨테이너를 포함합니다. 마치 아파트와 같습니다.
  • IP 주소 (IP Address): 네트워크에 연결된 장치에 할당되는 고유한 식별 주소입니다. 마치 집 주소와 같습니다.
  • 온-프레미스 클라이언트 (On-Premise Client): 클라우드 환경 외부에 있는 사용자 또는 시스템입니다.
  • 네트워크 유형 (Network Type): AKS 클러스터 내의 네트워크 구성 방식을 결정합니다.
  • Hybrid Connection: 온-프레미스 애플리케이션을 Azure 리소스에 안전하게 연결하는 데 사용됩니다.
  • Azure Private Link: 가상 네트워크 내의 개인 IP 주소를 통해 Azure 서비스에 비공개로 접근할 수 있도록 합니다.
  • Kubenet: AKS의 기본적인 네트워크 플러그인으로, 각 노드에 IP 주소가 할당되고 포드가 노드의 IP 주소를 공유합니다.
  • Azure CNI (Container Networking Interface): 각 포드에 고유한 IP 주소를 할당하여 포드 간 및 외부와의 직접적인 통신을 가능하게 하는 네트워크 플러그인입니다.

정답: D (온-프레미스 클라이언트가 포드의 IP 주소를 사용하여 직접 app1에 연결해야 하므로, 각 포드에 고유한 IP 주소를 할당하는 Azure CNI 네트워크 유형을 선택해야 합니다.)

 

문제 121

Subscription1이라는 Azure 구독에 다음 리소스가 있습니다.

  • rg1 (리소스 그룹)
  • rg2 (리소스 그룹)
  • vnet1 (가상 네트워크, rg1에 속함)
  • vnet2 (가상 네트워크, rg2에 속함)

vnet1과 vnet2 사이에는 연결이 없습니다. admin1이라는 관리자가 rg1에 vm1이라는 Azure 가상 머신을 만듭니다. vm1은 disk1이라는 디스크를 사용하고 vnet1에 연결됩니다. 그런 다음 admin1은 vm1에 사용자 지정 애플리케이션을 설치합니다. 사용자 지정 애플리케이션을 vnet2로 이동해야 하며, 솔루션은 관리 노력을 최소화해야 합니다. 어떤 두 가지 작업을 수행해야 할까요?

보기 (첫 번째 작업):

  • 가상 인터페이스(네트워크 인터페이스) 분리
  • vm1 삭제
  • rg2에 네트워크 인터페이스 만들기
  • 네트워크 인터페이스를 rg2로 이동

보기 (두 번째 작업):

  • 네트워크 인터페이스 연결
  • vm1을 rg2로 이동
  • rg2에 네트워크 인터페이스 만들기
  • 새 가상 머신 만들기

해설:

목표:
사용자 지정 애플리케이션이 설치된 vm1을 vnet2로 이동(즉, vnet2에 연결된 VM으로 재배치)하며, 관리 노력을 최소화해야 합니다.

핵심 사실 및 근거

  • Azure에서는 VM의 네트워크 인터페이스(NIC)를 다른 가상 네트워크(VNet)로 직접 이동할 수 없습니다.
  • VM을 한 VNet에서 다른 VNet으로 이동하려면, **VM을 삭제(디스크는 보존)**하고, 새 네트워크 인터페이스(NIC)를 대상 VNet에 만든 후, 기존 디스크로 새 VM을 생성해야 합니다.
  • 이 과정에서 VM을 삭제할 때 디스크(disk1)는 반드시 보존해야 하며, 새 VM을 만들 때 이 디스크를 사용하면 기존 애플리케이션과 데이터가 유지됩니다.

보기별 해설

첫 번째 작업(선택지)

  • 가상 인터페이스(네트워크 인터페이스) 분리: VM은 최소 하나의 NIC가 항상 필요하므로, 단독 분리는 불가.
  • vm1 삭제: 필요. VM을 삭제해야만 디스크를 보존하고 새 VNet에 연결할 수 있음.
  • rg2에 네트워크 인터페이스 만들기: 필요. vnet2에 연결된 새로운 NIC가 필요함.
  • 네트워크 인터페이스를 rg2로 이동: NIC를 다른 VNet으로 이동할 수 없음.

정답:

  • vm1 삭제
  • rg2에 네트워크 인터페이스 만들기

 

두 번째 작업(선택지)

  • 네트워크 인터페이스 연결: 새 VM을 만들 때 새 NIC를 연결하는 과정에 해당.
  • vm1을 rg2로 이동: 리소스 그룹만 이동해도 VNet 변경은 불가.
  • rg2에 네트워크 인터페이스 만들기: 이미 첫 번째 작업에서 선택.
  • 새 가상 머신 만들기: 기존 디스크(disk1)와 새 NIC를 사용해 새 VM을 만들어야 함.

정답:

  • 네트워크 인터페이스 연결
  • 새 가상 머신 만들기

최종 정답

가장 관리 노력이 적은 두 가지 작업은 다음과 같습니다:

  • 첫 번째 작업:
    vm1 삭제
  • 두 번째 작업:
    새 가상 머신 만들기

설명:

  1. vm1을 삭제(디스크는 보존)
  2. vnet2(rg2)에 새 NIC 생성
  3. 기존 디스크(disk1)와 새 NIC를 사용해 새 VM 생성

이 방식이 Azure 공식 가이드와 커뮤니티에서 제시하는 가장 표준적이고 관리 노력이 적은 방법입니다146.

 

  • 가상 머신 (Virtual Machine, VM): 클라우드에서 실행되는 가상의 컴퓨터입니다.
  • 디스크 (Disk): 가상 머신의 운영 체제, 애플리케이션 및 데이터를 저장하는 가상 하드 드라이브입니다.
  • 가상 네트워크 (Virtual Network, VNet): Azure에서 생성하는 사설 네트워크입니다.
  • 서브넷 (Subnet): 가상 네트워크를 논리적으로 분할한 것입니다.
  • 네트워크 인터페이스 (Network Interface): 가상 머신이 가상 네트워크와 통신하기 위한 인터페이스입니다. 마치 컴퓨터의 랜 카드와 같습니다.
  • 리소스 그룹 (Resource Group): 관련된 Azure 리소스들을 논리적으로 묶어 놓은 컨테이너입니다.
  • 관리 노력 최소화 (Minimize Administrative Effort): 작업을 수행하는 데 필요한 시간과 단계를 줄이는 것입니다.

정답:

첫 번째 작업: vm1 삭제 (하지만 디스크 disk1은 유지해야 합니다.) 두 번째 작업: 새 가상 머신 만들기 (vnet2에 연결하고 기존 디스크 disk1을 연결하여 사용자 지정 애플리케이션을 유지합니다.)

(설명: 가상 머신이 생성된 후에는 연결된 가상 네트워크를 변경할 수 없습니다. 따라서 기존 VM을 삭제하고 동일한 디스크를 사용하여 새 가상 네트워크에 새 VM을 만들어야 합니다. 이렇게 하면 애플리케이션을 다시 설치하는 노력을 줄일 수 있습니다.)

 

문제 122

Azure 구독에 storage1이라는 Azure 스토리지 계정이 있습니다. storage account one을 Azure Resource Manager 템플릿으로 내보냅니다. 템플릿에는 다음 섹션이 포함되어 있습니다.

{
  "$schema": "...",
  "contentVersion": "1.0.0.0",
  "parameters": { ... },
  "variables": { ... },
  "functions": [ ... ],
  "resources": [
    {
      "type": "Microsoft.Storage/storageAccounts",
      "apiVersion": "...",
      "name": "[parameters('storageAccountName')]",
      "location": "[resourceGroup().location]",
      "sku": {
        "name": "[parameters('accountType')]"
      },
      "kind": "[parameters('accountKind')]",
      "properties": {
        "networkAcls": {
          "defaultAction": "Allow",
          "virtualNetworkRules": [],
          "ipRules": []
        },
        "supportsHttpsTrafficOnly": true,
        "accessTier": "[parameters('accessTier')]"
      }
    }
  ],
  "outputs": { ... }
}

각각의 다음 설명이 참인지 거짓인지 선택하세요.

  • 공용 IP 주소가 131.107.103.10인 서버는 storage1에 액세스할 수 있습니다.
  • storage account one의 개별 Blob은 archive 계층을 사용하도록 설정할 수 있습니다.
  • Azure Active Directory의 전역 관리자는 해당 Azure AD 자격 증명을 사용하여 storage account one에 호스팅된 파일 공유에 액세스할 수 있습니다.

 

해설:

1. "공용 IP 주소가 131.107.103.10인 서버는 storage1에 액세스할 수 있습니다."

  • 정답: 참(True)
    이유:
    • ARM 템플릿에서 networkAcls.defaultAction이 Allow로 설정되어 있고, ipRules가 비어 있습니다.
    • Azure Storage 방화벽은 기본적으로 모든 공용 IP 주소의 접근을 허용하며, 특정 IP를 차단하려면 명시적으로 추가해야 합니다.
    • 따라서 131.107.103.10 IP는 차단 규칙이 없으므로 접근이 허용됩니다.

2. "storage account one의 개별 Blob은 archive 계층을 사용하도록 설정할 수 있습니다."

  • 정답: 참(True)
    이유:
    • Archive 계층은 Blob 단위로 설정 가능하며, 스토리지 계정의 기본 접근 계층(accessTier)과 무관합니다.
    • 템플릿에서 accessTier 파라미터가 존재하지만, 이는 스토리지 계정의 기본 계층을 지정하는 것이며, 개별 Blob의 계층 변경은 Set Blob Tier API 또는 Azure Portal에서 별도로 가능합니다.

3. "Azure Active Directory의 전역 관리자는 해당 Azure AD 자격 증명을 사용하여 storage account one에 호스팅된 파일 공유에 액세스할 수 있습니다."

  • 정답: 거짓(False)
    이유:
    • Azure Files의 AD DS 인증을 사용하려면 스토리지 계정을 온-프레미스 AD에 등록하고, share-level 권한을 명시적으로 할당해야 합니다.
    • 템플릿에 AD 통합 관련 설정(AzureFilesIdentityBasedAuth 등)이 없으므로, Azure AD 자격 증명만으로는 파일 공유 접근이 불가능합니다.
    • 전역 관리자라도 파일 공유에 대한 RBAC 또는 NTFS 권한이 없으면 접근할 수 없습니다.

요약 

번호 설명 정답
1 131.107.103.10 IP 서버 접근 가능 참
2 개별 Blob Archive 계층 사용 가능 참
3 Azure AD 전역 관리자의 파일 공유 접근 가능 거짓
 

 

  • Azure Resource Manager (ARM) 템플릿: Azure 리소스를 코드로 정의하여 자동으로 배포하고 관리할 수 있도록 하는 파일입니다.
  • Network ACLs (Network Access Control Lists): 스토리지 계정에 대한 네트워크 기반 접근 제어를 구성하는 설정입니다. defaultAction: Allow는 명시적으로 거부되지 않은 모든 트래픽을 허용한다는 의미입니다. virtualNetworkRules와 ipRules가 비어 있으므로 특정 가상 네트워크나 IP 주소에 대한 제한이 없습니다.
  • 액세스 계층 (Access Tier): Blob 데이터의 저장 비용과 접근 성능을 결정하는 설정입니다. Hot, Cool, Archive 계층이 있습니다. 스토리지 계정 수준에서 기본 액세스 계층을 설정할 수 있지만, 개별 Blob의 액세스 계층을 다르게 설정할 수도 있습니다 (StorageV2 계정 종류인 경우).
  • Azure Active Directory (Azure AD): 클라우드 기반의 ID 및 접근 관리 서비스입니다. (현재는 Microsoft Entra ID로 이름이 변경되었습니다.)
  • 전역 관리자 (Global Administrator): Azure AD 테넌트의 모든 측면에 대한 관리 권한을 가진 역할입니다.
  • 파일 공유 (File Share): Azure Files 서비스를 통해 생성된 네트워크 파일 공유입니다.
  • Azure 역할 기반 접근 제어 (Azure RBAC): Azure 리소스에 대한 접근 권한을 세밀하게 관리하는 시스템입니다. Azure AD 역할은 Azure 리소스에 대한 직접적인 접근 권한을 제공하지 않으며, Azure RBAC 역할을 별도로 할당해야 합니다.

정답:

  • 공용 IP 주소가 131.107.103.10인 서버는 storage1에 액세스할 수 있습니까? 예. (Network ACL의 기본 동작이 Allow이고, 특정 IP 규칙이 없기 때문입니다.)
  • storage account one의 개별 Blob은 archive 계층을 사용하도록 설정할 수 있습니까? 예. (StorageV2 계정 종류는 Blob 수준에서 액세스 계층을 변경하는 것을 지원합니다.)
  • Azure Active Directory의 전역 관리자는 해당 Azure AD 자격 증명을 사용하여 storage account one에 호스팅된 파일 공유에 액세스할 수 있습니까? 아니요. (Azure AD 역할만으로는 Azure 리소스에 직접 접근할 수 없습니다. 파일 공유에 접근하려면 Storage File Data RBAC 역할을 명시적으로 할당해야 합니다.)

 

문제 123

종량제 Azure 구독에 다음과 같은 가상 머신이 있습니다.

  • vm1 (rg1에 호스팅, 일일 비용 $2)
  • vm2 (rg2에 호스팅, 일일 비용 $30)

다음 그림과 같은 예산을 만듭니다. ag1이라는 액션 그룹에는 user1@contoso.com 사용자만 포함되어 있습니다. 그림 정보를 바탕으로 다음 문장을 완성하세요.

  • budget1의 최대 금액에 도달하면 어떻게 될까요?
  • 가상 머신의 현재 사용 비용을 기준으로 매달 몇 개의 이메일 알림이 전송될까요?

(그림 설명):

  • 예산 이름: budget1
  • 범위: rg1 (리소스 그룹)
  • 예산 금액: $1,000
  • 예산 기간: 매월 재설정
  • 경고 조건:
    • 50% 도달 시: 이메일 알림 (user1@contoso.com)
    • 70% 도달 시: SMS 알림
    • 100% 도달 시: Azure App 실행

해설:

 

1. budget1의 최대 금액에 도달하면 어떻게 될까요?

  • **Azure App 실행(100% 도달 시)**이 트리거됩니다.
    • 예산 설정에서 100% 도달 시 Azure App 실행으로 구성되어 있기 때문입니다1.

2. 매달 몇 개의 이메일 알림이 전송될까요?

  • 0개의 이메일 알림이 전송됩니다.

근거:

  • 예산 범위가 rg1이므로 **vm1(일일 $2)**의 비용만 계산됩니다.
  • vm1의 월간 총 비용: $2 × 30일 = $60 (예산 $1,000의 6%).
  • **50% 임계값($500)**에 도달하려면 250일($500 ÷ $2/일)이 필요하나, 예산 기간은 월간으로 설정되어 있어 실제로 도달할 수 없습니다.
  • 따라서 **이메일 알림(50% 도달 시)**은 한 번도 발송되지 않습니다.

요약 

항목 결과
예산 최대 금액 도달 시 Azure App 실행
월간 이메일 알림 횟수 0회
 

 

  • Azure 예산 (Azure Budget): Azure 구독 또는 리소스 그룹의 비용을 추적하고 관리하는 데 사용되는 서비스입니다.
  • 범위 (Scope): 예산이 적용되는 Azure 구독 또는 리소스 그룹입니다.
  • 예산 금액 (Budget Amount): 지정된 기간 동안 예상되는 최대 비용입니다.
  • 예산 기간 (Budget Period): 예산이 추적되는 시간 간격입니다.
  • 경고 조건 (Alert Condition): 비용이 특정 임계값에 도달했을 때 알림을 보내도록 설정하는 규칙입니다.
  • 액션 그룹 (Action Group): 경고가 발생했을 때 수행할 작업(예: 이메일 보내기, SMS 보내기, Azure App 실행)과 해당 작업을 수행할 대상을 정의합니다.
  • 종량제 (Pay-as-you-go): 사용한 만큼만 비용을 지불하는 Azure 구독 유형입니다.

정답:

  • budget1의 최대 금액에 도달하면 어떻게 될까요? vm1과 vm2는 계속 실행됩니다. (Azure 예산은 비용을 추적하고 알림을 보내는 기능만 제공하며, 리소스 사용을 자동으로 중단시키지는 않습니다.)
  • 가상 머신의 현재 사용 비용을 기준으로 매달 몇 개의 이메일 알림이 전송될까요? 매달 1개의 이메일 알림이 전송됩니다. (budget1의 범위는 rg1이므로 vm1의 비용만 추적합니다. vm1의 일일 비용은 $2이므로 월간 예상 비용은 약 $60입니다. 50% 임계값($500)을 훨씬 넘지 않으므로 50% 도달 시의 이메일 알림만 한 번 발생합니다.)

 

이 문제는 Azure 예산 및 경고 설정의 작동 방식을 이해하고, **예산 적용 범위(scope)**에 따라 경고가 어떻게 작동하는지를 파악하는 것이 핵심입니다.

🔍 조건 정리

  • vm1: rg1에 있음 / 일일 비용 $2
  • vm2: rg2에 있음 / 일일 비용 $30
  • 예산 이름: budget1
  • 예산 범위: rg1
  • 예산 금액: $1,000 / 매월 재설정

📩 예산 경고 조건

경고 조건동작
50% 이메일 (user1@contoso.com)
70% SMS 알림
100% Azure App 실행

✅ 문장 1:

"budget1의 최대 금액에 도달하면 어떻게 될까요?"

  • 예산 budget1은 rg1 범위에만 적용
  • vm1만 포함 (vm2는 rg2에 있어 예산에 영향 없음)
  • 100% 도달 시 설정은 "Azure App 실행"

🟩 정답 문장:
budget1의 최대 금액에 도달하면 Azure App이 실행됩니다.

✅ 문장 2:

"가상 머신의 현재 사용 비용을 기준으로 매달 몇 개의 이메일 알림이 전송될까요?"

  • vm1 일일 비용 = $2
  • 한 달 30일 기준 비용 = $2 × 30 = $60
  • 예산 $1,000 대비 60 / 1000 = 6% 수준
  • 경고 임계값(50%)에 도달하지 않음

🟩 정답 문장:
가상 머신의 현재 사용 비용을 기준으로 매달 0개의 이메일 알림이 전송됩니다.

✅ 최종 완성 문장

  • budget1의 최대 금액에 도달하면 Azure App이 실행됩니다.
  • 가상 머신의 현재 사용 비용을 기준으로 매달 0개의 이메일 알림이 전송됩니다.

 

 

문제 124

10개의 Azure 가상 머신을 Azure Automation State Configuration에 온보딩했고, Azure Automation State Configuration을 사용하여 가상 머신 구성의 지속적인 일관성을 관리해야 합니다. 순서대로 수행해야 하는 세 가지 작업은 무엇일까요?

보기:

  • 관리 그룹 만들기
  • 노드 준수 상태 확인
  • 가상 머신에 태그 할당
  • 구성을 노드 구성으로 컴파일
  • 구성을 Azure Automation State Configuration으로 가져오기

해설:

이 문제는 **Azure Automation State Configuration (DSC)**의 작업 흐름을 이해하는 것이 핵심입니다.
즉, 구성 파일을 준비하고 → 컴파일하고 → 가상 머신에 적용하는 순서입니다.

✅ 정답: 수행해야 하는 세 가지 작업 (순서대로)

  1. 구성을 Azure Automation State Configuration으로 가져오기
    • .ps1 또는 .mof 형식의 DSC 구성 스크립트를 Azure Automation에 업로드하는 단계
    • 예: Import-AzAutomationDscConfiguration 명령 사용
  2. 구성을 노드 구성으로 컴파일
    • 가져온 .ps1 파일을 **MOF(관리 객체 형식)**으로 컴파일하여 VM에 적용 가능한 형태로 변환
    • 예: Start-AzAutomationDscCompilationJob 사용
  3. 노드 준수 상태 확인
    • 각 VM이 구성대로 잘 설정되어 있는지 확인 (준수 상태: Compliant / NonCompliant)

❌ 오답 분석:

  • 관리 그룹 만들기 → Azure Policy나 리소스 제어용이지 DSC와 직접 관계 없음
  • 가상 머신에 태그 할당 → 태깅은 리소스 메타데이터 관리용이며, DSC 자체와 무관

🧩 최종 정답 (순서대로)

✅ 구성을 Azure Automation State Configuration으로 가져오기
✅ 구성을 노드 구성으로 컴파일
✅ 노드 준수 상태 확인

 

  • Azure Automation State Configuration: PowerShell Desired State Configuration (DSC)을 클라우드에서 관리하는 Azure 서비스입니다. 서버 구성의 일관성을 유지하고 관리하는 데 사용됩니다. 마치 여러 대의 컴퓨터 설정을 중앙에서 관리하는 시스템과 같습니다.
  • 온보딩 (Onboarding): Azure Automation State Configuration에서 관리할 가상 머신을 등록하는 과정입니다.
  • 지속적인 일관성 (Ongoing Consistency): 가상 머신의 구성이 시간이 지나도 원하는 상태를 유지하도록 관리하는 것입니다.
  • 관리 그룹 (Management Group): Azure 구독을 논리적으로 그룹화하여 정책 및 접근 제어를 계층적으로 관리하는 데 사용됩니다. State Configuration과는 직접적인 관련이 적습니다.
  • 노드 (Node): Azure Automation State Configuration에서 관리하는 가상 머신입니다.
  • 준수 상태 (Compliance Status): 노드의 현재 구성이 원하는 구성과 일치하는지 여부를 나타냅니다.
  • 태그 (Tag): Azure 리소스에 대한 메타데이터를 추가하는 것입니다. State Configuration과는 직접적인 관련이 적습니다.
  • 구성 (Configuration): 원하는 서버 상태를 PowerShell DSC 코드로 정의한 것입니다. 마치 서버 설정 설명서와 같습니다.
  • 노드 구성 (Node Configuration): 특정 노드에 적용할 구성을 컴파일한 결과물입니다.
  • 가져오기 (Import): 구성 PowerShell DSC 코드를 Azure Automation State Configuration 서비스로 업로드하는 것입니다.
  • 컴파일 (Compile): 가져온 구성을 특정 노드에 적용할 수 있는 노드 구성으로 변환하는 것입니다.
  • 확인 (Check): 노드의 현재 구성이 원하는 구성과 일치하는지 확인하는 것입니다.

정답:

  1. 구성을 Azure Automation State Configuration으로 가져오기 (Import configuration to Azure Automation State Configuration)
  2. 구성을 노드 구성으로 컴파일 (Compile configuration into node configuration)
  3. 노드 준수 상태 확인 (Check the compliance status of the node)

 

문제 125

Azure Cloud Shell에서 Azure Resource Manager 템플릿을 사용하여 가상 머신을 만들어야 합니다. 명령을 어떻게 완성해야 할까요?

$adminPassword = Read-Host -AsSecureString "Enter the Admin Password"

New-Az _______ -_______ _______ -_______ <구독 GUID> -TemplateUri <GitHub 템플릿 URI> -adminUsername "localadmin" -adminPassword $adminPassword -DNSPrefix "testvm1"

보기 (첫 번째 빈칸):

  • Resource
  • TemplateSpec
  • VM
  • ResourceGroupDeployment

보기 (두 번째 빈칸):

  • Tag
  • GroupName
  • ResourceGroupName
  • Subscription

보기 (세 번째 빈칸):

  • tag1
  • mg1
  • rg1
  • <구독 GUID>

보기 (네 번째 빈칸):

  • Tag
  • GroupName
  • ResourceGroupName
  • Subscription

해설:

이 문제는 Azure Cloud Shell에서 Azure Resource Manager (ARM) 템플릿을 사용하여 VM을 배포할 때 사용하는 New-AzResourceGroupDeployment 명령어의 정확한 구문을 묻는 것입니다.

🔧 핵심 구조 복습

Azure PowerShell에서 ARM 템플릿을 배포할 때 가장 일반적으로 사용하는 명령어:

New-AzResourceGroupDeployment -ResourceGroupName <RG 이름> -TemplateUri <템플릿 위치> -<매개변수들>

✅ 보기별 분석

첫 번째 빈칸 – New-Az_______

정답: ResourceGroupDeployment

  • 이 명령은 특정 리소스 그룹에 리소스를 배포할 때 사용

🟥 오답:

  • Resource → 리소스 하나 생성 시 사용
  • TemplateSpec → 템플릿 사양에서 배포할 때 사용
  • VM → 명령어로 존재하지 않음

두 번째 빈칸 – -_______

정답: ResourceGroupName

  • 배포 대상 리소스 그룹을 지정

🟥 오답:

  • Tag → 태그 지정과 무관
  • GroupName → 명확하지 않음
  • Subscription → 구독 정보는 다른 명령에서 설정

세 번째 빈칸 – _______ 값

정답: rg1

  • 위의 -ResourceGroupName에 대한 값으로 합리적

네 번째 빈칸 – -_______ <구독 GUID>

정답: Subscription

  • 명령어에서 구독 범위를 지정할 때 -Subscription 사용

✅ 최종 완성된 명령어:

$adminPassword = Read-Host -AsSecureString "Enter the Admin Password"

New-AzResourceGroupDeployment -ResourceGroupName rg1 -Subscription <구독 GUID> -TemplateUri <GitHub 템플릿 URI> -adminUsername "localadmin" -adminPassword $adminPassword -DNSPrefix "testvm1"

 

  • Azure Cloud Shell: 웹 브라우저를 통해 Azure를 관리할 수 있는 셸 환경입니다.
  • Azure Resource Manager (ARM) 템플릿: Azure 리소스를 코드로 정의하여 자동으로 배포하고 관리할 수 있도록 하는 파일입니다.
  • Read-Host -AsSecureString: PowerShell에서 사용자로부터 비밀번호와 같은 중요한 정보를 안전하게 입력받는 명령입니다.
  • New-AzResourceGroupDeployment: Azure PowerShell에서 기존 리소스 그룹에 ARM 템플릿을 배포하는 명령입니다. 가상 머신을 템플릿을 통해 배포하는 데 사용됩니다.
  • New-AzVM: Azure PowerShell에서 직접 가상 머신을 만드는 명령입니다. 템플릿 URI를 직접 파라미터로 받지 않습니다.
  • New-AzResource: Azure의 일반적인 리소스를 만드는 명령입니다.
  • New-AzTemplateSpec: ARM 템플릿 사양을 관리하는 명령입니다.
  • -ResourceGroupName: ARM 템플릿을 배포할 기존 리소스 그룹의 이름을 지정하는 파라미터입니다.
  • -Subscription: 사용할 Azure 구독을 지정하는 파라미터입니다.
  • -TemplateUri: 배포할 ARM 템플릿 파일의 URI (Uniform Resource Identifier, 일반적으로 웹 주소)를 지정하는 파라미터입니다.
  • -adminUsername, -adminPassword, -DNSPrefix: 가상 머신 생성 시 필요한 관리자 계정 정보와 DNS 관련 설정을 지정하는 파라미터입니다.
  • 기존 리소스 그룹 (Existing Resource Group): 이미 Azure에 생성되어 있는 리소스 그룹입니다.

정답:

New-Az ResourceGroupDeployment - ResourceGroupName rg1 - Subscription <구독 GUID> -TemplateUri <GitHub 템플릿 URI> -adminUsername "localadmin" -adminPassword $adminPassword -DNSPrefix "testvm1"

(설명: 기존 리소스 그룹(rg1)에 ARM 템플릿을 배포하여 가상 머신을 생성하는 것이 목표이므로 New-AzResourceGroupDeployment 명령을 사용해야 합니다. 템플릿 URI를 지정하기 위한 -TemplateUri 파라미터는 New-AzVM 명령에는 없습니다.)

 

문제 126

다음 Azure 가상 네트워크가 있습니다.

  • vnet1: 10.1.0.0/16 (subnet1: 10.1.0.0/24), West US
  • vnet2: 10.2.0.0/16 (subnet2: 10.2.0.0/24), West US
  • vnet3: 10.3.0.0/16 (subnet3: 10.3.0.0/24), Central Europe
  • vnet4: 10.2.0.0/24 (subnet4: 10.2.0.0/28), Central Europe

vnet2에서 어떤 가상 네트워크와 피어링 연결을 설정할 수 있을까요?

보기:

A. vnet1 만 B. vnet1 및 vnet3 만 C. vnet3 및 vnet4 만 D. vnet1, vnet3 및 vnet4

해설:

 

이 문제는 **가상 네트워크 피어링(VNet Peering)**의 주요 제한 조건인 주소 공간 중복과 지역을 고려해야 합니다.

🔍 조건 분석

피어링 연결의 주요 제한 조건:

  1. 주소 공간이 겹치면 안 된다 (중복 안됨)
  2. 지역이 달라도 피어링 가능함 (Global VNet Peering 사용)

📦 VNet 정보 분석

VNet 주소 공간 서브넷 지역

vnet1 10.1.0.0/16 10.1.0.0/24 West US
vnet2 10.2.0.0/16 10.2.0.0/24 West US
vnet3 10.3.0.0/16 10.3.0.0/24 Central Europe
vnet4 10.2.0.0/24 ⚠️ 10.2.0.0/28 Central Europe

⚠️ 중복 확인

  • ✅ vnet1 (10.1.0.0/16) → 중복 없음
  • ✅ vnet3 (10.3.0.0/16) → 중복 없음
  • ❌ vnet4 (10.2.0.0/24) → vnet2와 주소 공간 중복!

vnet2: 10.2.0.0/16
vnet4: 10.2.0.0/24 → 이건 10.2.0.0/16 안에 포함됨 → 중복

✅ 최종 판단

vnet2는 다음과 피어링 가능:

  • vnet1 → ✅
  • vnet3 → ✅ (지역 달라도 가능)
  • vnet4 → ❌ (주소 공간 중복)

✅ 정답: B. vnet1 및 vnet3 만

 

  • 가상 네트워크 피어링 (Virtual Network Peering): 서로 다른 가상 네트워크 간에 사설 IP 주소를 사용하여 연결을 생성하여 마치 하나의 가상 네트워크처럼 통신할 수 있도록 하는 Azure 기능입니다. 마치 옆집과 뒷문을 통해 자유롭게 드나들 수 있도록 연결하는 것과 같습니다.
  • 주소 공간 (Address Space): 가상 네트워크에 할당된 IP 주소 범위입니다.
  • 서브넷 (Subnet): 가상 네트워크를 논리적으로 분할한 것입니다. 각 서브넷 내에서 IP 주소 범위를 할당합니다.
  • 겹치는 주소 공간 (Overlapping Address Spaces): 서로 다른 가상 네트워크에 동일하거나 겹치는 IP 주소 범위가 할당된 경우 피어링을 설정할 수 없습니다. 마치 옆집과 우리 집의 주소가 똑같으면 우편물이 섞일 수 있는 것과 같습니다.
  • 지역 간 피어링 (Cross-region Peering): 서로 다른 Azure 지역에 있는 가상 네트워크 간에 피어링을 설정하는 것입니다.

정답: B (vnet2(10.2.0.0/16)는 vnet1(10.1.0.0/16)과 vnet3(10.3.0.0/16)과는 주소 공간이 겹치지 않으므로 피어링을 설정할 수 있습니다. 하지만 vnet4(10.2.0.0/24)는 vnet2의 주소 공간과 겹치므로 피어링을 설정할 수 없습니다.)

 

문제 127

subnet1이라는 서브넷을 포함하는 vnet1이라는 가상 네트워크가 있습니다. subnet1에는 세 개의 Azure 가상 머신이 있으며 각 가상 머신에는 공용 IP 주소가 있습니다. 가상 머신은 인터넷 사용자가 포트 443을 통해 액세스할 수 있는 여러 애플리케이션을 호스팅합니다. 온-프레미스 네트워크는 vnet1에 대한 사이트 간 VPN 연결을 가지고 있으며, VM이 인터넷과 온-프레미스 네트워크 모두에서 RDP를 통해 액세스할 수 있다는 것을 발견했습니다. 인터넷에서 가상 머신으로의 RDP 액세스를 방지해야 합니다. 솔루션은 온-프레미스 네트워크에서 RDP 연결이 설정된 경우를 제외하고 모든 애플리케이션이 인터넷 사용자에게 계속 액세스 가능하도록 해야 합니다. 이 요구 사항을 어떻게 충족할 수 있을까요?

보기:

A. subnet1에 연결된 네트워크 보안 그룹(NSG)에 거부 규칙 만들기 B. subnet1의 주소 공간 수정 C. 로컬 네트워크 게이트웨이의 주소 공간 수정 D. 가상 머신에서 공용 IP 주소 제거

 

 

해설:

이 시나리오의 핵심은 다음 조건을 동시에 만족하는 솔루션을 찾는 것입니다:

🎯 요구 사항 요약

  • 가상 머신은 **공용 IP를 통해 애플리케이션(HTTPS)**을 인터넷에 제공해야 함 (포트 443)
  • **RDP 포트(3389)**는 인터넷에서 차단, 그러나
  • 온-프레미스에서는 RDP 허용되어야 함
  • 온-프레미스는 vnet1과 Site-to-Site VPN 연결되어 있음

🔍 각 선택지 검토

A. subnet1에 연결된 네트워크 보안 그룹(NSG)에 거부 규칙 만들기 ✅

  • NSG는 소스 IP 주소 및 포트 번호 기준으로 접근 제어 가능
  • 온-프레미스 주소 범위 (예: 10.0.0.0/16) 에는 3389 허용
  • 인터넷(Any 또는 0.0.0.0/0) 에 대해서는 3389 거부
  • 💡 HTTPS 포트(443)는 계속 허용할 수 있음

✅ 이 옵션은 요구 사항을 모두 충족함

B. subnet1의 주소 공간 수정 ❌

  • 서브넷 주소 공간을 수정한다고 해서 RDP 차단되지 않음
  • 네트워크 보안에는 영향 없음

❌ 관련 없음

C. 로컬 네트워크 게이트웨이의 주소 공간 수정 ❌

  • 이는 온-프레미스 네트워크에 대한 라우팅 정의에 관련
  • 외부에서 오는 RDP 차단과는 무관

❌ 관련 없음

D. 가상 머신에서 공용 IP 주소 제거 ❌

  • 공용 IP 제거하면 HTTPS 접근도 끊김
  • 요구 사항 위배

❌ 애플리케이션의 인터넷 액세스를 막게 됨

✅ 정답: A. subnet1에 연결된 네트워크 보안 그룹(NSG)에 거부 규칙 만들기

예시 규칙 설정:

우선순위 소스 포트 동작 설명
100 온-프레미스 IP 범위 (예: 10.0.0.0/16) 3389 허용 온-프레미스에서 RDP 허용
200 Any (0.0.0.0/0) 3389 거부 인터넷에서 RDP 차단
300 Any 443 허용 HTTPS 애플리케이션 액세스 유지

 

  • 서브넷 (Subnet): 가상 네트워크를 논리적으로 분할한 것입니다.
  • 공용 IP 주소 (Public IP Address): 인터넷을 통해 직접 액세스할 수 있는 IP 주소입니다.
  • RDP (Remote Desktop Protocol) 포트 3389: Windows 기반 컴퓨터에 원격으로 접속하는 데 사용되는 표준 네트워크 포트입니다. 마치 원격으로 컴퓨터 화면을 보는 것과 같습니다.
  • HTTPS (Hypertext Transfer Protocol Secure) 포트 443: 웹 브라우저와 웹 서버 간의 보안 통신에 사용되는 표준 네트워크 포트입니다. 웹사이트 주소 앞에 https://가 붙은 경우 이 포트를 사용합니다.
  • 온-프레미스 네트워크 (On-Premise Network): 클라우드 환경이 아닌 자체 데이터 센터나 서버실에 있는 네트워크입니다.
  • 사이트 간 VPN (Site-to-Site VPN): 온-프레미스 네트워크와 Azure 가상 네트워크 간에 보안 터널을 만들어 연결하는 것입니다. 마치 두 건물을 잇는 비밀 통로와 같습니다.
  • 네트워크 보안 그룹 (Network Security Group, NSG): Azure 리소스에 대한 인바운드 및 아웃바운드 네트워크 트래픽을 제어하는 방화벽 역할을 하는 서비스입니다.
  • 거부 규칙 (Deny Rule): 특정 네트워크 트래픽을 차단하는 NSG 규칙입니다.
  • 허용 규칙 (Allow Rule): 특정 네트워크 트래픽을 허용하는 NSG 규칙입니다.
  • 주소 공간 (Address Space): 가상 네트워크 또는 서브넷에 할당된 IP 주소 범위입니다.
  • 로컬 네트워크 게이트웨이 (Local Network Gateway): 온-프레미스 VPN 장치를 Azure에 표현하는 것입니다.

정답: A (subnet1에 연결된 NSG에 인터넷(소스 IP 주소 범위: 0.0.0.0/0)에서 포트 3389로 들어오는 트래픽을 거부하는 인바운드 규칙을 만들면 인터넷에서의 RDP 접근을 차단하면서, 이미 설정된 온-프레미스 VPN 연결을 통한 RDP 접근과 포트 443을 통한 웹 애플리케이션 접근은 허용할 수 있습니다.)

 

문제 128

Azure 구독에 site1과 site2라는 두 개의 온-프레미스 위치가 있습니다. Azure Virtual WAN을 사용하여 site1과 site2를 연결해야 합니다. 순서대로 수행해야 하는 네 가지 작업은 무엇일까요?

보기:

  1. Virtual WAN 리소스 만들기
  2. VPN 사이트 만들기
  3. VPN 사이트를 허브에 연결
  4. 가상 허브 만들기
  5. 가상 네트워크를 허브에 연결

 

해설:

Azure Virtual WAN을 사용하여 두 개의 온-프레미스 사이트(site1, site2) 간 연결을 설정하려면, Virtual WAN 아키텍처의 기본 구성요소를 순차적으로 구성해야 합니다. 목적은 site1과 site2가 Azure Virtual WAN 허브를 통해 상호 통신할 수 있도록 연결을 구성하는 것입니다.

✅ 올바른 수행 순서 (4단계)

1. Virtual WAN 리소스 만들기

  • 전체 Virtual WAN 환경을 위한 컨테이너 생성
  • 허브, VPN, ExpressRoute, 사용자 VPN 등을 구성할 기반

2. 가상 허브 만들기

  • Virtual WAN 내에서 네트워크 트래픽을 라우팅하는 중앙 허브
  • 지역(Region)마다 허브 하나

3. VPN 사이트 만들기

  • 온-프레미스 위치(site1, site2)를 Azure에 등록
  • 각 사이트의 공용 IP, 주소 공간 등을 지정

4. VPN 사이트를 허브에 연결

  • site1, site2와 허브를 VPN으로 연결
  • 이 연결을 통해 site1 ↔ site2 간 간접 통신이 가능

⛔ 선택지 중 포함되지 않아야 할 항목

  • **"가상 네트워크를 허브에 연결"**은 Virtual WAN 허브와 Azure 가상 네트워크 간 연결을 위한 것이며, 이번 목적(두 온-프레미스 사이트 간 연결)에는 필요 없습니다.

🧠 최종 정리

순서대로 수행해야 할 작업:

✅ 1. Virtual WAN 리소스 만들기
✅ 2. 가상 허브 만들기
✅ 3. VPN 사이트 만들기
✅ 4. VPN 사이트를 허브에 연결

 

  • Azure Virtual WAN: 대규모 WAN 연결을 단순화하고 자동화하는 네트워킹 서비스입니다. 여러 온-프레미스 위치, Azure 가상 네트워크 및 원격 사용자를 연결하는 데 사용됩니다. 마치 여러 도시를 연결하는 고속도로 네트워크의 중앙 관리 시스템과 같습니다.
  • Virtual WAN 리소스: Virtual WAN의 최상위 리소스입니다.
  • 가상 허브 (Virtual Hub): Virtual WAN 내의 핵심 네트워킹 지점입니다. VPN 게이트웨이, ExpressRoute 게이트웨이, Azure Firewall 등 다양한 서비스를 포함할 수 있습니다. 마치 고속도로 네트워크의 주요 분기점과 같습니다.
  • VPN 사이트: 온-프레미스 VPN 장치 및 연결 정보를 Virtual WAN에 표현한 것입니다.
  • VPN 연결: VPN 사이트와 가상 허브 간의 VPN 터널입니다.

정답:

  1. Virtual WAN 리소스 만들기
  2. 가상 허브 만들기
  3. VPN 사이트 만들기
  4. VPN 사이트를 허브에 연결

(설명: Virtual WAN을 사용하여 온-프레미스 사이트를 연결하는 기본적인 순서는 Virtual WAN 리소스를 만들고, 중앙 연결 지점인 가상 허브를 구성한 다음, 각 온-프레미스 위치를 VPN 사이트로 등록하고 가상 허브에 연결하는 것입니다.)

 

문제 129

Azure 구독이 있습니다. 사용자는 집 또는 회사 사이트에서 구독의 리소스에 액세스합니다. 집에서 사용자는 Azure 리소스에 액세스하기 위해 지점 대 사이트 VPN을 설정해야 합니다. 회사 사이트의 사용자는 사이트 간 VPN을 사용하여 Azure 리소스에 액세스합니다. 여러 Azure 가상 머신에서 실행되는 app1이라는 기간 업무 앱이 있습니다. app1에 대한 연결이 모든 가상 머신에 분산되도록 해야 합니다. 사용할 수 있는 두 가지 Azure 서비스는 무엇일까요?

보기:

  • Traffic Manager
  • Public Load Balancer
  • Azure Content Delivery Network (CDN)
  • Azure Application Gateway
  • Internal Load Balancer

 

해설:

이 시나리오에서는 사용자가 집과 회사 양쪽에서 Azure의 app1에 연결하며, 여러 Azure 가상 머신에서 실행 중인 app1에 대한 트래픽 부하 분산이 핵심 목표입니다.

✅ 목적 정리:

  • 집: Point-to-Site VPN으로 Azure에 접근
  • 회사: Site-to-Site VPN으로 Azure에 접근
  • app1은 여러 VM에서 실행되며, 모든 VM에 트래픽이 분산되어야 함

🎯 정답:

✅ Public Load Balancer

  • 인터넷 및 VPN을 통한 외부 트래픽을 여러 VM으로 부하 분산
  • VM이 공용 IP 또는 Load Balancer의 IP를 통해 서비스

✅ Azure Application Gateway

  • L7(Application Layer) 부하 분산
  • SSL 종료, 웹 애플리케이션 방화벽(WAF), URL 기반 라우팅 기능 포함
  • **VM이 웹 앱(app1)**을 호스팅할 경우 특히 적합

❌ 제외되는 옵션:

Traffic Manager

  • DNS 기반 라우팅 서비스로, 글로벌 배포 시 유용
  • 부하 분산이 아닌 위치 기반 라우팅이나 장애 조치 목적

Azure CDN

  • 정적 콘텐츠(예: 이미지, 동영상) 전송 최적화 용도
  • VM 기반 앱에 대한 트래픽 분산 목적과는 무관

Internal Load Balancer

  • 내부 네트워크 전용 트래픽 분산
  • VPN 사용자나 외부 사용자는 접근 불가

📌 정리:

정답: Public Load Balancer, Azure Application Gateway

이 조합은 앱이 외부에서 접근 가능한 웹 애플리케이션이라면 부하 분산 및 보안 요구를 모두 충족합니다.

 

  • 지점 대 사이트 VPN (Point-to-Site VPN): 개별 클라이언트 컴퓨터에서 Azure 가상 네트워크로 보안 연결을 만드는 것입니다. 마치 집에서 회사 네트워크에 VPN으로 접속하는 것과 같습니다.
  • 사이트 간 VPN (Site-to-Site VPN): 온-프레미스 네트워크와 Azure 가상 네트워크 간에 영구적인 보안 연결을 만드는 것입니다.
  • 기간 업무 앱 (Line of Business App): 조직의 핵심 업무 프로세스를 지원하는 애플리케이션입니다.
  • 부하 분산 (Load Balancing): 들어오는 네트워크 트래픽을 여러 서버에 분산시켜서 서비스의 가용성과 응답성을 높이는 것입니다.
  • Traffic Manager: DNS 기반의 트래픽 라우팅 서비스로, 전역적으로 트래픽을 분산하는 데 사용됩니다. 가상 머신 내부의 부하 분산과는 직접적인 관련이 적습니다.
  • Public Load Balancer: 인터넷에서 들어오는 트래픽을 Azure 가상 네트워크 내의 여러 가상 머신에 분산하는 서비스입니다. 공용 IP 주소를 통해 접근 가능합니다.
  • Azure Content Delivery Network (CDN): 정적 콘텐츠(이미지, 비디오 등)를 전 세계의 분산된 서버에 캐싱하여 사용자에게 더 빠르고 안정적으로 제공하는 서비스입니다. 애플리케이션 트래픽 부하 분산과는 관련이 적습니다.
  • Azure Application Gateway: 웹 애플리케이션 트래픽을 관리하고 라우팅하는 레이어 7 부하 분산 장치입니다. URL 경로 기반 라우팅, SSL 종료, 웹 애플리케이션 방화벽(WAF) 등의 고급 기능을 제공합니다. 공용 및 내부 부하 분산에 모두 사용할 수 있습니다.
  • Internal Load Balancer: Azure 가상 네트워크 내에서 트래픽을 여러 가상 머신에 분산하는 서비스입니다. 개인 IP 주소를 사용하며, 가상 네트워크 내부의 애플리케이션 부하 분산에 사용됩니다.

정답: Azure Application Gateway 및 Internal Load Balancer

(설명: 외부 트래픽(지점 대 사이트 VPN 및 인터넷)과 내부 트래픽(사이트 간 VPN에서 오는 트래픽이 가상 네트워크 내부에 도달한 후) 모두 app1을 호스팅하는 여러 가상 머신에 분산시키려면 Azure Application Gateway (외부 및 내부 트래픽 부하 분산에 사용 가능하며, 레이어 7 라우팅 기능 제공)와 Internal Load Balancer (가상 네트워크 내부의 트래픽 부하 분산에 사용)를 사용할 수 있습니다.)

 

문제 130

다음 그림과 같은 사용자 지정 역할을 구성합니다.

(그림 설명: JSON 형식의 사용자 지정 역할 정의)

  • roleName: "role1"
  • description: "Custom Role One"
  • assignableScopes: ["/subscriptions/<구독 ID>"]
  • permissions: [ { actions: [ "Microsoft.Compute/virtualMachines/read", "Microsoft.Compute/virtualMachines/restart/action", "Microsoft.Network/virtualNetworks/read", "Microsoft.Network/virtualNetworks/subnets/join/action", "Microsoft.Support/*" ], notActions: [], dataActions: [], notDataActions: [] } ]

그림 정보를 바탕으로 다음 문장을 완성하세요.

  • role1이 할당된 사용자가 가상 머신에 로그인할 수 있도록 하려면 ______ 섹션을 수정해야 합니다.
  • role1을 rg1이라는 리소스 그룹에만 할당할 수 있도록 하려면 ______ 섹션을 수정해야 합니다.

 

해설:

이 사용자 지정 역할 정의 JSON에 기반해서 다음 문장을 다음과 같이 완성할 수 있습니다:

✅ 첫 번째 문장:

“role1이 할당된 사용자가 가상 머신에 로그인할 수 있도록 하려면 permissions 섹션을 수정해야 합니다.”

  • 이유:
    현재 actions에 "Microsoft.Compute/virtualMachines/read" 및 "restart/action" 권한은 있지만, 로그인(RDP/SSH) 또는 Virtual Machine Contributor 수준의 권한이 없기 때문에, 사용자가 VM에 직접 로그인하려면 Microsoft.Compute/virtualMachines/login/action 같은 액션 또는 Virtual Machine User Login 역할에 해당하는 액션을 추가해야 합니다.
    즉, login 권한을 주기 위해선 permissions.actions를 수정해야 합니다.

✅ 두 번째 문장:

“role1을 rg1이라는 리소스 그룹에만 할당할 수 있도록 하려면 assignableScopes 섹션을 수정해야 합니다.”

  • 이유:
    현재 assignableScopes는 ["/subscriptions/<구독 ID>"]로 설정되어 있어서, 이 구독 내 모든 리소스 그룹 및 리소스에 할당 가능합니다.
    이를 /subscriptions/<구독 ID>/resourceGroups/rg1으로 변경하면 rg1 리소스 그룹에만 할당 가능하도록 제한할 수 있습니다.

✅ 요약:

  • permissions: 로그인 권한 추가 (예: Microsoft.Compute/virtualMachines/login/action)
  • assignableScopes: 역할의 할당 범위 조정 (예: 특정 리소스 그룹만)

  • 사용자 지정 역할 (Custom Role): Azure 리소스에 대한 세분화된 권한을 정의하기 위해 사용자가 직접 만드는 역할입니다.
  • roleName: 역할의 이름입니다.
  • description: 역할에 대한 설명입니다.
  • assignableScopes: 역할을 할당할 수 있는 Azure 리소스의 범위(구독, 리소스 그룹 등)를 지정합니다.
  • permissions: 역할이 가진 권한을 정의합니다.
    • actions: 허용되는 Azure 리소스 관리 작업 목록입니다. 예: 가상 머신 읽기 (Microsoft.Compute/virtualMachines/read), 가상 머신 재시작 (Microsoft.Compute/virtualMachines/restart/action).
    • notActions: 명시적으로 금지된 Azure 리소스 관리 작업 목록입니다.
    • dataActions: 데이터 평면 작업에 대한 권한 목록입니다. 예: 스토리지 계정 내의 Blob 데이터 읽기.
    • notDataActions: 명시적으로 금지된 데이터 평면 작업 목록입니다.
  • 데이터 평면 작업 (Data Plane Operations): 리소스 자체의 관리 작업(제어 평면)이 아닌 리소스 내의 데이터에 대한 작업입니다. 예: 스토리지 Blob 데이터 읽기/쓰기, Key Vault 비밀 읽기.
  • 제어 평면 작업 (Control Plane Operations): Azure 리소스 자체를 만들고 관리하는 작업입니다. 예: 가상 머신 만들기/삭제, 네트워크 구성 변경.

정답:

  • role1이 할당된 사용자가 가상 머신에 로그인할 수 있도록 하려면 dataActions 섹션을 수정해야 합니다. (가상 머신 로그인은 데이터 평면 작업이므로 Microsoft.Compute/virtualMachines/login/action 또는 관련 데이터 작업 권한을 dataActions에 추가해야 합니다.)
  • role1을 rg1이라는 리소스 그룹에만 할당할 수 있도록 하려면 assignableScopes 섹션을 수정해야 합니다. (현재 구독 수준으로 설정되어 있으므로, 리소스 그룹의 전체 경로(/subscriptions/<구독 ID>/resourceGroups/rg1)로 수정해야 합니다.)

'인공지능,프로그래밍 > MS Azure' 카테고리의 다른 글

AZ104 연습문제 1~10 요약  (0) 2025.04.28
가상 머신(VM) 관련 문제 분석  (0) 2025.04.28
AZ-104 시험 대비 문제 we-part1  (0) 2025.04.22
AZ-104 시험 대비 문제 we-part3  (0) 2025.04.22
Azure 주요 용어들의 상관 관계  (0) 2025.04.21

'인공지능,프로그래밍/MS Azure' Related Articles

티스토리툴바