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

Azure 관리자 시험 대비 문제 (AZ-104)

문제 131

vm1이라는 Azure 가상 머신과 kb1이라는 Azure Key Vault가 있습니다.

vm1에 Azure Disk Encryption을 구성하여 키 암호화 키를 사용하려고 합니다.

디스크 암호화를 위해 kb1을 준비해야 합니다.

어떤 암호화 방법을 사용해야 할까요?

보기:

A. Azure Disk Encryption

B. Customer-Managed Keys

C. Confidential Disk Encryption

D. Encryption at Host

✅ 해설:

질문은 Key Vault(kb1) 를 디스크 암호화에 사용할 수 있도록 어떻게 준비해야 하는지에 대한 것입니다.

이때 필요한 암호화 방법은 Customer-managed keys (CMK) 입니다.

Azure Disk Encryption에서 사용하는 암호화 흐름:

Azure는 디스크를 암호화할 Volume Encryption Key (VEK) 를 생성합니다.
이 VEK를 Customer-Managed Key (CMK) 로 암호화하여 보호합니다.
CMK는 Azure Key Vault (kb1) 에 저장되어 있어야 하며, Key Vault는 CMK 암호화를 지원하도록 구성되어 있어야 합니다.

보기 항목 분석:

A. Azure Disk Encryption
→ Azure 기능 자체이므로, Key Vault의 암호화 방식을 묻는 질문에 적절하지 않음.
B. Customer-managed keys ✅
→ 정확히 Key Vault에 적용해야 할 암호화 방식. 정답.
C. Confidential disk encryption
→ Confidential VM에서만 사용하는 기능. 일반 VM에서는 사용되지 않음.
D. Encryption at Host
→ 디스크 암호화가 아닌, 호스트 인프라 레벨에서의 암호화로 Key Vault와 관련 없음.

Azure 가상 머신 (Azure Virtual Machine, VM): 클라우드에서 실행되는 가상의 컴퓨터입니다.
Azure Key Vault: 암호화 키, 비밀 (예: 암호), 인증서를 안전하게 저장하고 관리하는 서비스입니다. 마치 은행의 금고와 같습니다.
Azure Disk Encryption (ADE): Azure VM의 OS 및 데이터 디스크를 암호화하는 서비스입니다.
키 암호화 키 (Key Encryption Key, KEK): 데이터 암호화 키를 암호화하는 데 사용되는 추가 보안 계층입니다. Key Vault에 저장됩니다.
Customer-managed keys: 사용자가 직접 암호화 키를 생성하고 관리하는 방식입니다. ADE와 함께 사용하여 VM 디스크를 암호화할 수 있습니다.
Confidential disk encryption: 사용 중인 데이터를 포함하여 VM 디스크 전체를 암호화하여 무단 액세스를 방지하는 고급 보안 기능입니다. 특정 VM 유형에서 지원됩니다.
Encryption at Host: VM의 호스트 서버에서 데이터를 암호화하고, Azure Storage에 저장될 때도 암호화된 상태를 유지하는 방식입니다.

정답: A (Azure Disk Encryption은 OS 및 데이터 디스크 암호화, Key Vault에 키 저장 및 사용, Azure에서 다운로드 시에도 암호화 유지 등의 요구 사항을 모두 충족하는 적절한 방법입니다.)

문제 132

storage1이라는 Azure 스토리지 계정이 있는 Azure 구독이 있습니다. subscription1은 온-프레미스 Active Directory 도메인과 동기화되는 contoso.com이라는 Azure AD 테넌트에 연결되어 있습니다. 도메인에는 다음 보안 주체가 있습니다.

user1 (사용자)
computer1 (컴퓨터)

Azure AD에는 user2라는 사용자가 있습니다. storage1에는 share1이라는 파일 공유가 있으며 다음과 같이 구성되어 있습니다.

종류: StorageV2
Azure Files identity based authentication: 사용
Directory Services 옵션: AD
Active Directory 속성

: DomainName = contoso.com, NetBiosDomainName = contoso.com , forestName = contoso.com

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

share1에 대한 Storage File Data SMB Share Reader 역할을 computer1에 할당할 수 있습니다.
share1에 대한 Storage File Data SMB Share Contributor 역할을 user1에 할당할 수 있습니다.

해설 :

이 질문은 Azure Files의 Active Directory 기반 인증 설정과 역할 할당 가능 여부를 평가하는 것입니다. 설정된 정보와 역할 조건을 기반으로 문장을 분석해볼게요.

📌 조건 요약:

스토리지 계정 이름: storage1
파일 공유 이름: share1
스토리지 계정 종류: StorageV2 (Azure Files 지원)
인증 방식: Azure Files identity based authentication 사용
Directory Services 옵션: AD (즉, 온-프레미스 Active Directory 연동)
AD 도메인 정보: 도메인 및 포리스트 이름이 poo.com

📍 보안 주체 목록:

user1: 온-프레미스 AD 사용자
computer1: 온-프레미스 AD 컴퓨터 계정
user2: Azure AD 사용자 (온-프레미스 AD와는 별도)

✅ 진위 판단:

✳️ 문장 1:

“share1에 대한 Storage File Data SMB Share Reader 역할을 computer1에 할당할 수 있습니다.”

이 역할은 Azure RBAC 역할이며, 일반적으로 사용자 또는 그룹에 할당합니다.
컴퓨터 계정 (computer1) 은 RBAC 역할의 일반적인 대상이 아닙니다.
또한, Azure는 컴퓨터 계정에 직접 Azure RBAC 역할을 할당할 수 없습니다.

🔹 결론: ❌ 거짓

✳️ 문장 2:

“share1에 대한 Storage File Data SMB Share Contributor 역할을 user1에 할당할 수 있습니다.”

user1은 온-프레미스 Active Directory 사용자이고, 설정된 AD 도메인(poo.com)에 속해 있다고 가정됩니다.
share1은 Azure Files AD 인증을 사용하고 있으며, Directory Services는 AD로 설정됨.
user1은 Azure RBAC 대상이 될 수 있으므로 Storage File Data SMB Share Contributor 역할 할당이 가능합니다.

🔹 결론: ✅ 참

🔚 정리:

설명	판단
share1에 대한 Storage File Data SMB Share Reader 역할을 computer1에 할당할 수 있다.	❌ 거짓
share1에 대한 Storage File Data SMB Share Contributor 역할을 user1에 할당할 수 있다.	✅ 참

Azure Storage 계정 (Azure Storage Account): Azure에서 데이터를 저장하는 기본적인 단위입니다.
Azure AD 테넌트 (Azure Active Directory Tenant): 조직을 위한 클라우드 기반의 ID 및 접근 관리 서비스의 독립적인 인스턴스입니다. (현재는 Microsoft Entra ID로 이름이 변경되었습니다.)
온-프레미스 Active Directory (AD) 도메인: 조직 내부에서 사용자, 컴퓨터 및 기타 개체를 관리하는 데 사용되는 Microsoft의 디렉터리 서비스입니다.
동기화 (Synchronization): 온-프레미스 AD와 Azure AD 간에 사용자 및 그룹 정보를 일치시키는 과정입니다.
보안 주체 (Security Principal): 시스템에서 인증 및 권한 부여를 위해 사용될 수 있는 사용자, 그룹, 서비스 주체 또는 컴퓨터 개체입니다.
Azure Files identity based authentication: Azure Files 파일 공유에 접근할 때 Azure AD 또는 온-프레미스 AD 자격 증명을 사용하는 기능입니다.
Directory Services 옵션: AD: Azure Files 인증에 Active Directory를 사용하도록 구성되었음을 나타냅니다.
Storage File Data SMB Share Reader: SMB를 통해 Azure 파일 공유의 파일 및 디렉터리를 읽을 수 있는 권한을 제공하는 RBAC 역할입니다.
Storage File Data SMB Share Contributor: SMB를 통해 Azure 파일 공유의 파일 및 디렉터리를 읽기, 쓰기, 삭제할 수 있는 권한을 제공하는 RBAC 역할입니다.
SMB (Server Message Block): Windows 파일 공유 (네트워크 드라이브)에 사용되는 네트워크 프로토콜입니다.

정답:

share1에 대한 Storage File Data SMB Share Reader 역할을 computer1에 할당할 수 있습니까? 아니요. (Azure Files RBAC 역할은 사용자 및 그룹에 할당할 수 있지만, 컴퓨터 개체에는 직접 할당할 수 없습니다.)
share1에 대한 Storage File Data SMB Share Contributor 역할을 user1에 할당할 수 있습니까? 예. (user1은 온-프레미스 AD와 동기화된 Azure AD 사용자이며, Azure Files 인증이 AD로 구성되어 있으므로 해당 역할 할당이 가능합니다.)

문제 133

10개의 Azure 구독이 있습니다. group1이라는 Azure Active Directory 테넌트와 보안 그룹이 있으며,

추가 Azure 구독을 구매할 계획입니다.

group1이 기존 구독과 계획된 구독 모두에 대한 역할 할당을 관리할 수 있도록 해야 합니다.

솔루션은 최소 권한 원칙을 준수하고 관리 노력을 최소화해야 합니다.

무엇을 해야 할까요?

보기:

A. 새 관리 그룹을 만들고 group1에 그룹에 대한 User Access Administrator 역할 할당

B. 새 관리 그룹을 만들고 group1에 그룹에 대한 Owner 역할 할당

C. group1에 루트 관리 그룹에 대한 Owner 역할 할당

D. group1에 루트 관리 그룹에 대한 User Access Administrator 역할 할당

해설:

이 문제는 Azure 구독 전체에 대한 중앙 집중적 권한 관리 체계를 설정하려는 것입니다.
핵심 포인트는 다음과 같습니다:

✅ 요구 조건 분석

10개의 기존 Azure 구독 + 새로 추가될 구독
**group1 (AAD 보안 그룹)**이 모든 구독의 역할 할당을 관리해야 함
최소 권한 원칙 준수
관리 노력 최소화

🎯 목표

group1이 **구독 전체(기존 + 향후 생성 포함)**에 대해 역할 할당을 관리할 수 있어야 하며,
필요 이상 권한은 없어야 합니다.

🔍 보기 분석

보기	설명	평가
A. 새 관리 그룹 생성 + User Access Administrator 할당	특정 하위 구조에만 적용됨. 향후 구독이 해당 그룹에 포함되지 않으면 적용되지 않음	❌ 불완전
B. 새 관리 그룹 생성 + Owner 역할 할당	Owner는 너무 많은 권한 부여 (리소스 삭제, 생성 등 포함) → 최소 권한 원칙 위배	❌ 과도한 권한
C. group1에 루트 관리 그룹에 Owner 역할 할당	모든 하위 구독에 대해 완전한 통제권 (역할 할당 포함) 가능하지만 권한 과도	❌ 권한 과다, 원칙 위배
✅ D. group1에 루트 관리 그룹에 User Access Administrator 역할 할당	모든 구독 포함 관리 가능 + 역할 할당 전용 권한 → 최소 권한 원칙 충족	✅ 정답

✅ 정답:

D. group1에 루트 관리 그룹에 대한 User Access Administrator 역할 할당

📌 이유

User Access Administrator는 리소스에 RBAC 역할을 할당/제거할 수 있는 권한만 가짐
루트 관리 그룹에 할당하면, 모든 현재 및 향후 구독에 대해 권한 관리 가능
최소 권한 원칙에 부합하며, 관리 노력도 최소화됨

Azure 구독 (Azure Subscription): Azure 서비스를 사용하기 위한 계정입니다.
Azure AD 테넌트 (Azure Active Directory Tenant): 조직을 위한 클라우드 기반의 ID 및 접근 관리 서비스의 독립적인 인스턴스입니다. (현재는 Microsoft Entra ID로 이름이 변경되었습니다.)
보안 그룹 (Security Group): 사용자들을 모아서 권한을 쉽게 할당하고 관리하기 위한 그룹입니다.
관리 그룹 (Management Group): Azure 구독을 논리적으로 그룹화하여 정책 및 접근 제어를 계층적으로 관리하는 데 사용됩니다. 루트 관리 그룹은 모든 관리 그룹의 최상위 그룹입니다.
역할 할당 (Role Assignment): 특정 보안 주체(사용자, 그룹 등)에게 특정 범위(구독, 리소스 그룹 등)에 대한 특정 역할(권한 집합)을 부여하는 것입니다.
최소 권한 원칙 (Principle of Least Privilege): 작업 수행에 필요한 최소한의 권한만 부여해야 한다는 보안 원칙입니다.
User Access Administrator: Azure 리소스에 대한 사용자 액세스를 관리할 수 있는 역할입니다 (역할 할당 생성 및 관리 포함).
Owner: Azure 리소스에 대한 모든 권한을 가지며, 다른 사용자에게 권한을 위임할 수도 있는 역할입니다.
관리 노력 최소화 (Minimize Administrative Effort): 작업을 수행하는 데 필요한 단계와 시간을 줄이는 것입니다.

정답: D (group1에 루트 관리 그룹에 대한 User Access Administrator 역할을 할당하면 group1은 모든 기존 및 계획된 구독에 대한 역할 할당을 관리할 수 있게 됩니다. Owner 역할보다 적은 권한을 부여하므로 최소 권한 원칙을 준수하며, 루트 수준에서 한 번만 할당하면 되므로 관리 노력을 최소화할 수 있습니다.)

문제 134

Azure 구독에 다음과 같은 두 개의 가상 머신이 있습니다.

vm1: Windows Server 2022, East US 2, DNS 서버: 기본 (Azure 제공), IP 주소: 10.0.0.4
vm2: Windows Server 2019, East US 2, DNS 서버: 기본 (Azure 제공), IP 주소: 10.0.0.5

vm2에서 10.0.0.4에 대한 역방향 DNS 조회를 수행합니다. 어떤 FQDN이 반환될까요?

보기:

A. vm1.eastus.cloudapp.azure.com

B. vm1.core.windows.net

C. vm1.internal.cloudapp.net

D. vm1.azure.com

해설:

이 문제는 Azure 기본 DNS 설정을 사용하는 환경에서의 역방향 DNS 조회 (reverse DNS lookup) 결과를 묻는 것입니다.

🔍 전제 조건 요약

두 VM은 동일한 리전에 있음 (East US 2)
동일한 Azure Virtual Network (가정)
DNS 서버는 Azure 기본 DNS
IP 주소:
- vm1 → 10.0.0.4
- vm2 → 10.0.0.5
vm2에서 10.0.0.4에 대해 역방향 조회 실행

🔄 역방향 DNS란?

역방향 DNS 조회는 IP 주소를 통해 해당하는 FQDN(Fully Qualified Domain Name)을 알아내는 방식입니다. 일반적으로 Azure에서 기본 DNS를 사용하고, 해당 가상 네트워크 안에서 조회할 경우 다음과 같은 형식을 따릅니다:

<vm-name>.<region>.internal.cloudapp.net

이 네이밍은 Azure 내부 DNS 시스템이 관리하는 기본 포맷입니다. 공개 DNS에서 보이지 않으며, 가상 네트워크 내부에서만 유효합니다.

✅ 정답 분석

A. vm1.eastus.cloudapp.azure.com
→ Azure 외부 DNS 사용 시의 FQDN 형식. X
B. vm1.core.windows.net
→ 예전 Azure Classic VM의 호스트 이름 형식. 현재는 사용되지 않음. X
C. vm1.internal.cloudapp.net
→ Azure 기본 DNS가 제공하는 가상 네트워크 내부의 호스트 이름 형식. ⭕ 유력
D. vm1.azure.com
→ 실제 존재하지 않는 도메인 포맷. X

🎯 최종 정답

✅ C. vm1.internal.cloudapp.net

Azure 가상 머신 (Azure Virtual Machine, VM): 클라우드에서 실행되는 가상의 컴퓨터입니다.
DNS 서버 (Domain Name System Server): 도메인 이름을 IP 주소로 변환하는 서버입니다. 마치 전화번호부와 같습니다.
기본 DNS 서버 (Default DNS Server): Azure에서 자동으로 제공하는 DNS 서버입니다.
IP 주소 (IP Address): 네트워크에 연결된 장치에 할당되는 고유한 식별 주소입니다.
역방향 DNS 조회 (Reverse DNS Lookup): IP 주소를 사용하여 해당 IP 주소에 연결된 도메인 이름을 확인하는 과정입니다.
FQDN (Fully Qualified Domain Name): 호스트 이름과 모든 상위 도메인 이름을 포함하는 전체 도메인 이름입니다. 마치 웹사이트의 전체 주소와 같습니다.
*.internal.cloudapp.net: Azure에서 관리하는 역방향 DNS 영역으로, Azure VM에 자동으로 할당되는 기본 FQDN 형식입니다.

정답: C (Azure 관리 역방향 DNS 레코드는 VM 시작 시 vmname.internal.cloudapp.net 형식으로 자동 추가되고, VM이 중지되거나 할당 취소되면 제거됩니다. 따라서 기본 DNS 서버를 사용하는 Azure VM의 역방향 DNS 조회 결과는 일반적으로 .internal.cloudapp.net 도메인으로 끝납니다.)

문제 135

여러 온-프레미스 위치와 Azure 가상 네트워크 간에 경로 기반 사이트 간 VPN 연결을 배포하려고 합니다.

어떤 터널링 프로토콜을 사용해야 할까요?

보기:

A. PPTP

B. IKEv1

C. IKEv2

D. L2TP

해설:

이 질문은 Azure와 온-프레미스 간의 사이트 간 VPN 연결에 적합한 터널링 프로토콜을 묻고 있습니다.

핵심은 “경로 기반(Route-based) VPN”이라는 점입니다. 이걸 기준으로 각 프로토콜을 분석하죠.

🔑 핵심 포인트: 경로 기반 VPN

경로 기반 VPN은 IPSec 터널 인터페이스와 라우팅 테이블을 기반으로 작동합니다.
Azure에서 경로 기반 VPN을 사용하려면 IKEv2를 기반으로 하는 터널이 필요합니다.
정책 기반 VPN은 보통 IKEv1 + ACL/정책 설정으로 작동합니다.

보기 분석

A. PPTP (Point-to-Point Tunneling Protocol)

오래된 프로토콜
보안 취약점 존재
Azure에서 지원되지 않음 → ❌

B. IKEv1

정책 기반 VPN에서 사용
경로 기반 VPN과는 비호환 → ❌

C. IKEv2

경로 기반 VPN에서 필수로 사용됨
Azure 사이트 간 VPN의 기본 터널링 프로토콜
성능 및 보안 측면에서 IKEv1보다 우수 → ✅

D. L2TP (Layer 2 Tunneling Protocol)

주로 사용자-대상 VPN에서 사용
Azure 사이트 간 VPN에서는 사용하지 않음 → ❌

✅ 최종 정답

✅ C. IKEv2

경로 기반 VPN (Route-based VPN): VPN 터널을 통해 어떤 네트워크 트래픽을 보낼지 경로(라우팅 테이블)를 기반으로 결정하는 VPN 방식입니다.
사이트 간 VPN (Site-to-Site VPN): 온-프레미스 네트워크와 Azure 가상 네트워크 간에 영구적인 보안 연결을 만드는 것입니다.
터널링 프로토콜 (Tunneling Protocol): 네트워크를 통해 데이터를 안전하게 전송하기 위해 사용되는 통신 규약입니다. 마치 데이터를 담는 비밀 상자와 같습니다.
PPTP (Point-to-Point Tunneling Protocol): 오래된 VPN 프로토콜로, 보안 취약점이 있어 더 이상 권장되지 않습니다.
IKEv1 (Internet Key Exchange version 1): VPN 터널을 설정하고 보안 연결을 협상하는 데 사용되는 프로토콜입니다. 비교적 오래되었으며, 일부 제한 사항이 있습니다.
IKEv2 (Internet Key Exchange version 2): IKEv1의 개선된 버전으로, 더 나은 성능, 향상된 보안 기능 및 네트워크 변경에 대한 더 나은 처리 능력을 제공합니다. 최신 VPN 배포에 권장되는 프로토콜입니다.
L2TP (Layer 2 Tunneling Protocol): 자체적으로는 암호화를 제공하지 않으며, 일반적으로 IPsec과 함께 사용하여 보안 VPN 연결을 만듭니다.

정답: C (경로 기반 사이트 간 VPN 연결에는 IKEv2를 사용하는 것이 성능, 보안 및 안정성 측면에서 가장 좋습니다.)

문제 136

다음 그림과 같은 계층 구조를 포함하는 Azure 구독이 있습니다. policy1이라는 Azure Policy 정의를 만듭니다. policy1을 어떤 Azure 리소스에 할당할 수 있으며, 어떤 Azure 리소스를 policy1에서 제외할 수 있을까요?

🔧 계층 구조

[테넌트 루트 그룹]
      └── [관리 그룹 1]
             └── [구독 1]
                    └── [리소스 그룹 1]
                           └── [가상 머신 1]

해설:

이 문제는 **Azure Policy의 할당 범위(Scope)**와 제외(Exclusion) 개념을 묻는 구조 문제입니다.

🎯 핵심 개념: Azure Policy 할당과 제외

Policy 할당(Scope): Azure Policy는 관리 그룹, 구독, 리소스 그룹, 리소스(예: VM) 수준에 할당 가능함.
제외(Exclusion): 할당된 범위 내부의 특정 리소스를 예외 처리할 수 있음.
즉, 할당은 상위부터 가능하며, 예외는 하위 요소에서 지정.

✅ policy1을 할당할 수 있는 대상

아래는 policy1을 할당할 수 있는 모든 유효 범위입니다:

테넌트 루트 그룹
관리 그룹 1
구독 1
리소스 그룹 1
가상 머신 1 (단독 리소스에도 할당 가능)

✅ policy1에서 제외할 수 있는 대상

제외는 할당된 범위 내부에 있는 리소스여야 합니다. 예를 들어 구독 1에 policy1을 할당하면:

리소스 그룹 1 제외 가능
가상 머신 1 제외 가능
하지만 관리 그룹 1이나 구독 2 (다른 구독) 등은 제외 불가

📌 예시

할당: 구독 1, 제외: 리소스 그룹 1 또는 VM 1 → ✅ 가능
할당: 관리 그룹 1, 제외: 구독 1 또는 그 하위 리소스 → ✅ 가능
할당: 리소스 그룹 1, 제외: 가상 머신 1 → ✅ 가능
할당: 가상 머신 1, 제외: 없음 → 리소스에 할당 시 더 하위 리소스는 없음

✅ 정리

policy1을 할당할 수 있는 리소스:
테넌트 루트 그룹, 관리 그룹 1, 구독 1, 리소스 그룹 1, 가상 머신 1
policy1에서 제외할 수 있는 리소스:
policy1이 할당된 범위 내의 하위 리소스들 (예: VM 1, 리소스 그룹 1)

Azure 정책 (Azure Policy): Azure 리소스에 대한 규칙을 정의하고 적용하여 규정 준수를 유지하고 리소스를 관리하는 서비스입니다.
정책 정의 (Policy Definition): 적용할 규칙을 구체적으로 정의한 것입니다.
정책 할당 (Policy Assignment): 정의된 정책을 특정 범위(관리 그룹, 구독, 리소스 그룹, 개별 리소스)에 적용하는 것입니다.
범위 (Scope): 정책이 할당되는 Azure 리소스의 계층 수준입니다.
제외 (Exclusion): 정책 할당 범위 내에서 특정 리소스를 정책 적용 대상에서 제외하는 것입니다.
테넌트 루트 그룹 (Tenant Root Group): Azure AD 테넌트의 최상위 관리 그룹입니다. 모든 관리 그룹, 구독 및 리소스가 이 그룹 아래에 속합니다.
관리 그룹 (Management Group): Azure 구독을 논리적으로 그룹화하여 정책 및 접근 제어를 계층적으로 관리하는 데 사용됩니다.
구독 (Subscription): Azure 서비스를 사용하기 위한 계정입니다.
리소스 그룹 (Resource Group): 관련된 Azure 리소스들을 논리적으로 묶어 놓은 컨테이너입니다.
개별 리소스 (Individual Resource): 가상 머신, 스토리지 계정 등과 같은 특정 Azure 리소스입니다.

정답:

policy1을 할당할 수 있는 Azure 리소스: 테넌트 루트 그룹, 관리 그룹 1, 구독 1, 리소스 그룹 1, 가상 머신 1 (정책 정의 또는 이니셔티브는 Azure가 지원하는 모든 범위의 리소스에 할당할 수 있습니다.)
policy1에서 제외할 수 있는 Azure 리소스: 관리 그룹 1, 구독 1, 리소스 그룹 1, 가상 머신 1 (정책 할당 시 가장 높은 범위는 제외할 수 없습니다. 테넌트 루트 그룹에 정책을 할당하면서 테넌트 루트 그룹 자체를 제외할 수는 없습니다.)

문제 137

app1이라는 Azure App Service 웹앱이 있습니다.

Web Deploy를 사용하여 app1을 배포하려고 합니다.

app1의 개발자가 Azure AD 자격 증명을 사용하여 app1에 콘텐츠를 배포할 수 있도록 해야 합니다.

솔루션은 최소 권한 원칙을 준수해야 합니다. 무엇을 해야 할까요?

보기:

A. FTPS에 대한 사용자 수준 자격 증명 구성

B. FTPS에 대한 앱 수준 자격 증명 구성

C. 개발자에게 Owner 역할 할당

D. 개발자에게 Website Contributor 역할 할당

해설:

이 문제는 Azure App Service(Web App)에 Web Deploy로 배포할 때,

Azure AD 기반 인증을 활용하면서도 최소 권한 원칙을 따르는 적절한 역할을 선택하는 문제입니다.

🔍 요구사항 요약

배포 대상: app1 (Azure App Service)
배포 방법: Web Deploy (즉, MSDeploy)
인증 방식: Azure AD 자격 증명 사용
보안 원칙: 최소 권한

🔐 Azure App Service에 Web Deploy + Azure AD 사용 방법

**Web Deploy (MSDeploy)**는 기본적으로 발행 프로필 또는 FTP/FTPS 자격 증명을 통해 인증하지만, **Azure AD 기반 역할 기반 액세스 제어 (RBAC)**를 사용할 수도 있음.
이 경우, 적절한 Azure RBAC 역할을 부여함으로써 Azure AD 자격 증명을 통한 배포가 가능함.
Azure AD를 사용할 경우, 리소스에 대한 직접적인 관리자 권한은 불필요.

🧐 보기 분석

A. FTPS에 대한 사용자 수준 자격 증명 구성

FTPS는 일반적으로 사용자/비밀번호 기반 인증
Azure AD 자격 증명 사용 아님 → ❌

B. FTPS에 대한 앱 수준 자격 증명 구성

마찬가지로 Azure AD 인증이 아님
또한 FTPS는 MSDeploy보다 낮은 수준의 보안 → ❌

C. 개발자에게 Owner 역할 할당

Owner는 구독 수준까지 모든 리소스 제어 가능
지나치게 과도한 권한 → 최소 권한 원칙 위반 → ❌

D. 개발자에게 Website Contributor 역할 할당

이 역할은 App Service 리소스에 대해 관리 권한은 없지만 배포(Write) 가능
App Service에 대한 배포 권한만 제공하며, Azure AD 자격 증명 사용 가능
최소 권한 원칙에 부합 → ✅

✅ 최종 정답

✅ D. 개발자에게 Website Contributor 역할 할당

Azure App Service: 웹 애플리케이션, API 등을 빌드, 배포, 확장할 수 있는 PaaS 서비스입니다.
Web Deploy: 웹 애플리케이션 및 관련 파일을 웹 서버에 배포하는 Microsoft 도구입니다.
Azure AD 자격 증명: Azure Active Directory (현재 Microsoft Entra ID) 사용자의 로그인 정보입니다.
최소 권한 원칙: 작업 수행에 필요한 최소한의 권한만 부여해야 한다는 보안 원칙입니다.
FTPS (FTP over SSL/TLS): 보안 연결을 통해 파일을 전송하는 프로토콜입니다.
사용자 수준 자격 증명: 특정 사용자에게만 FTPS 접근 권한을 부여하는 것입니다.
앱 수준 자격 증명: App Service 앱 전체에 대한 FTPS 접근 권한을 부여하는 것입니다.
Owner 역할: Azure 구독의 모든 리소스에 대한 전체 권한을 제공하는 역할입니다.
Website Contributor 역할: App Service 앱을 관리할 수 있는 권한(콘텐츠 배포 포함)을 제공하지만, 기반 인프라에 대한 권한은 제한적인 역할입니다.

정답: D (Website Contributor 역할은 개발자가 App Service 앱에 콘텐츠를 배포하는 데 필요한 최소한의 권한만 제공하므로 최소 권한 원칙을 준수합니다. Owner 역할은 너무 많은 권한을 부여하며, FTPS 사용자/앱 수준 자격 증명은 Azure AD 통합을 직접 사용하지 않습니다.)

문제 138

Windows Server 2016을 실행하는 vm1이라는 Azure 가상 머신이 있습니다.

vm1에서 한 시간 이내에 시스템 이벤트 로그에 2개 이상의 오류 이벤트가 기록되면 Azure에 경고를 만들어야 합니다.

Azure Log Analytics 작업 영역을 만들고 데이터 설정을 구성하는 솔루션을 제공합니다.

그런 다음 vm1에 Microsoft Monitoring Agent를 설치합니다.

Monitor에서 경고를 만들고 Log Analytics 작업 영역을 소스로 지정합니다.

이 솔루션이 목표를 충족합니까?

해설:

네, 이 솔루션은 목표를 정확하게 충족합니다.

🎯 목표 다시 정리

대상: vm1 (Windows Server 2016)
조건: 1시간 이내에 시스템 이벤트 로그에 오류 이벤트가 2개 이상 기록되면
동작: Azure에서 경고(Alert) 생성

✅ 솔루션 검토

1. Log Analytics 작업 영역 생성

로그 데이터 저장소 역할
다양한 리소스의 진단 로그, 이벤트 로그, 성능 데이터 수집 가능

2. 이벤트 로그 수집 설정

Windows 이벤트 로그(예: System, Application)를 수집 대상으로 지정
"오류" 수준 이벤트(Level 2)를 필터링할 수 있음

3. Microsoft Monitoring Agent 설치

VM1에 직접 설치 → Log Analytics 작업 영역과 연결됨
Windows 이벤트 로그 포함하여 VM 데이터를 전송

4. Azure Monitor 경고 생성

데이터 소스로 Log Analytics 작업 영역 지정
KQL 쿼리로 조건 설정: 예를 들어,

Event
| where TimeGenerated > ago(1h)
| where EventLog == "System" and Level == 2
| summarize ErrorCount = count()
| where ErrorCount >= 2

이 쿼리에 기반하여 조건 충족 시 경고 발생

✅ 결론

이 솔루션은 다음 이유로 정확히 목표를 달성합니다:

정확한 이벤트 로그 수집
시간 조건(1시간 이내) 고려
오류 이벤트 수(2개 이상) 필터링 가능
경고 자동화 설정 가능

✅ 정답: 예, 이 솔루션은 목표를 충족합니다.

Azure 가상 머신 (Azure Virtual Machine, VM): 클라우드에서 실행되는 가상의 컴퓨터입니다.
시스템 이벤트 로그 (System Event Log): Windows 운영 체제에서 시스템 관련 이벤트(오류, 경고, 정보 등)를 기록하는 로그입니다.
Azure Monitor: Azure 리소스 및 애플리케이션의 가용성 및 성능 데이터를 수집, 분석하고 이에 대한 경고를 제공하는 서비스입니다.
Azure Log Analytics 작업 영역 (Azure Log Analytics Workspace): Azure Monitor 로그 데이터를 저장하고 분석하는 중앙 집중식 저장소입니다.
Microsoft Monitoring Agent (MMA): Windows 및 Linux 운영 체제에서 Azure Monitor에 데이터를 수집하는 에이전트입니다.
경고 (Alert): 특정 조건이 충족되면 알림을 보내도록 구성된 규칙입니다.

정답: 예.

(제공된 솔루션은 Azure Monitor를 사용하여 가상 머신의 시스템 이벤트 로그를 모니터링하고,

지정된 오류 이벤트 수에 도달하면 경고를 생성하는 올바른 방법입니다.)

문제 139

storage1이라는 Azure 스토리지 계정이 있는 Azure 구독이 있습니다.

역할 기반 접근 제어(RBAC) 역할을 storage1에 할당할 때 조건을 사용하려고 합니다.

역할을 할당할 때 조건을 지원하는 다음 storage1 서비스는 무엇일까요?

보기:

A. 큐

B. 파일 공유

C. 컨테이너

D. 테이블

E. 파일 공유 및 테이블 만

F. 컨테이너 및 큐 만

해설:

이 문제는 Azure Storage 리소스에 대한 RBAC 조건부 액세스(Condition-based RBAC) 기능이 어떤 서비스에 적용 가능한가를 묻고 있습니다.

🔍 핵심 개념: 조건부 RBAC (Role-Based Access Control with Conditions)

2023년 이후, Azure는 특정 스토리지 서비스에 대해 조건을 포함하는 RBAC 기능을 점진적으로 지원 중입니다.
조건 예: Blob 이름 접두사(prefix), 컨테이너 이름, 요청의 IP 주소 등
그러나 이 기능은 모든 스토리지 서비스에 지원되지 않습니다.

✅ 조건 기반 RBAC이 지원되는 스토리지 서비스 (2024 기준)

스토리지 서비스 조건 기반	RBAC 지원 여부
Blob (컨테이너)	✅ 지원됨
Queue (큐)	✅ 지원됨
File (파일 공유)	❌ 미지원
Table (테이블)	❌ 미지원

📌 Microsoft 공식 문서 참조:

Azure Storage는 Blob 및 Queue 서비스에 대해 조건부 RBAC을 지원하며, File 및 Table 서비스는 현재 지원하지 않습니다.
🔗 Docs: Azure Storage conditional access with Azure RBAC

✅ 최종 정답

✅ F. 컨테이너 및 큐 만

Azure 스토리지 계정 (Azure Storage Account): Azure에서 데이터를 저장하는 기본적인 단위입니다.
역할 기반 접근 제어 (Role-Based Access Control, RBAC): Azure 리소스에 대한 접근 권한을 세밀하게 관리하는 시스템입니다.
조건 (Condition): RBAC 역할 할당 시 특정 조건이 충족될 때만 권한이 적용되도록 하는 것입니다. 예를 들어, 특정 IP 주소에서 오는 요청에만 특정 역할을 허용할 수 있습니다.
큐 (Queue): 메시지 기반 통신을 위한 Azure Storage 서비스입니다.
파일 공유 (File Share): 클라우드에서 접근 가능한 파일 공유를 제공하는 Azure Files 서비스입니다.
컨테이너 (Container): Blob Storage 내에서 데이터를 저장하는 폴더와 같은 개념입니다.
테이블 (Table): NoSQL 키-값 데이터 저장소인 Azure Table Storage 서비스입니다.
Blob Storage 데이터 작업 (Blob Storage Data Actions): Blob 데이터를 읽기, 쓰기, 삭제하는 등의 작업입니다.
Queue Storage 데이터 작업 (Queue Storage Data Actions): 큐에 메시지를 넣고 빼는 등의 작업입니다.

정답: F (현재 조건은 Blob Storage 또는 Queue Storage 데이터 작업을 포함하는 기본 제공 또는 사용자 지정 역할 할당에만 추가할 수 있습니다.)

문제 140

subscription1이라는 Azure 구독에 다음 할당량이 있습니다.

Standard BS family 가상 CPU: East Europe 위치, 할당량 20개
Standard D family 가상 CPU: East Europe 위치, 할당량 20개
East Europe 총 지역 CPU: 20개

다음 표와 같이 가상 머신을 subscription1에 배포합니다.

vm1: Standard B2ms, East Europe, vCPU 2개, 상태: 실행 중
vm2: Standard B6ms, East Europe, vCPU 16개, 상태: 중지됨 (할당 취소됨)

다음 표와 같은 가상 머신을 배포하려고 합니다.

vm3: Standard B1ms, East Europe, vCPU 1개
vm4: Standard D4as v5, East Europe, vCPU 4개
vm5: Standard B8ms, East Europe, vCPU 16개

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

vm3를 East Europe에 배포할 수 있습니다.
vm4를 East Europe에 배포할 수 있습니다.
vm5를 East Europe에 배포할 수 있습니다.

해설:

이 문제는 Azure 구독의 가상 머신(vCPU) 할당량과 할당 상태를 기준으로, 새로운 VM들을 배포할 수 있는지를 판단하는 문제입니다. 각각의 조건을 정확히 따져봐야 합니다.

🎯 주어진 조건 요약

✅ 현재 구독의 할당량

항목	수량
Standard BS family (B 시리즈)	20 vCPU
Standard D family	20 vCPU
East Europe 지역 전체 할당량	20 vCPU (총합 기준)

✅ 현재 배포된 VM

VM	사이즈	Family	vCPU	상태	vCPU 점유
vm1	B2ms	BS	2	실행 중	2개 사용 중
vm2	B6ms	BS	16	중지됨 (할당 취소됨)	0개 사용 중

⛳ "중지됨(할당 취소됨)"은 vCPU가 반환된 상태 → 할당량에 영향 없음

📌 현재 사용 중인 할당량:

BS family: 2개 사용 중 (2/20)
D family: 0개 사용 중 (0/20)
지역 전체: 2개 사용 중 (2/20)

✅ 추가로 배포할 VM

VM	사이즈	Family	vCPU
vm3	B1ms	BS	1
vm4	D4as v5	D	4
vm5	B8ms	BS	16

🔍 각 VM 배포 가능 여부 분석

🔸 vm3: B1ms (BS family, 1 vCPU)

현재 BS family: 2 사용 중 → 18 남음
지역 전체: 2 사용 중 → 18 남음
✅ 가능

🔸 vm4: D4as v5 (D family, 4 vCPU)

D family: 0 사용 중 → 20 남음
지역 전체: 2 사용 중 → 18 남음
D family 4 + 기존 2 = 6 → 지역 허용 (20) 이내
✅ 가능

🔸 vm5: B8ms (BS family, 16 vCPU)

BS family: 현재 2 사용 중
vm5는 16 vCPU 필요 → 총합 18 vCPU
BS family 허용: 20 → 2 + 16 = 18 → OK
지역 전체 허용: 2 + 1(vm3) + 4(vm4) + 16(vm5) = 23 vCPU ❗ 초과됨

🚫 지역 전체 한도 20개 초과
❌ 불가능

✅ 정답 요약

vm3를 East Europe에 배포할 수 있습니다.	✅ 참
vm4를 East Europe에 배포할 수 있습니다.	✅ 참
vm5를 East Europe에 배포할 수 있습니다.	❌ 거짓 (지역 총량 초과)

할당량 (Quota): Azure 구독 또는 지역별로 사용할 수 있는 리소스의 최대 제한입니다.
가상 CPU (vCPU): 가상 머신에 할당되는 논리적 CPU 코어 수입니다.
가상 머신 크기 (Virtual Machine Size): 가상 머신에 할당되는 vCPU, 메모리 등의 리소스 양을 결정합니다. Standard B 시리즈와 Standard D 시리즈는 서로 다른 워크로드에 최적화된 VM 크기입니다.
지역별 총 CPU (Total Regional CPUs): 특정 Azure 지역에서 사용할 수 있는 모든 VM 시리즈의 총 vCPU 할당량입니다. 이 할당량은 모든 VM 시리즈의 vCPU 사용량을 합한 값으로 제한됩니다.
가상 머신 상태 (Virtual Machine State): 가상 머신의 현재 상태(실행 중, 중지됨, 할당 취소됨 등)입니다. 할당 취소된 VM은 vCPU 할당량에 포함되지 않습니다.

정답:

vm3를 East Europe에 배포할 수 있습니까? 예. (현재 실행 중인 vm1은 2개의 vCPU를 사용하고, 할당 취소된 vm2는 vCPU 할당량에 영향을 미치지 않습니다. vm3에 1개의 vCPU를 추가하면 총 사용량은 3개로, 지역별 총 CPU 할당량 20개 이내이므로 배포 가능합니다.)
vm4를 East Europe에 배포할 수 있습니까? 아니요. (vm1(2개) + vm3(1개) + vm4(4개) = 7개의 vCPU를 Standard D family 할당량 20개 이내로 사용할 수 있지만, ~~Standard BS family 할당량은 이미 vm1(2개) + vm3(1개) = 3개를 사용하고 있으므로~~ ~~vm5(16개)를 추가하면 Standard BS family 할당량을 초과합니다.~~ ~~또한 지역별 총 CPU 할당량 20개도 초과하게 됩니다.)~~
vm5를 East Europe에 배포할 수 있습니까? 아니요. (vm1(2개) + vm3(1개) + vm5(16개) = 19개의 vCPU를 Standard BS family 할당량 20개 이내로 사용할 수 있지만, vm4(4개)를 배포할 수 없는 이유와 마찬가지로 지역별 총 CPU 할당량 20개를 초과하게 됩니다.)

문제 141

Azure 구독에 다음과 같은 리소스가 있습니다.

리소스 그룹: rg1 (Australia East)
리소스 그룹: rg2 (Australia Central)
가상 머신 확장 집합: vmss1 (rg2, Australia Central)
근접 배치 그룹: proximity1 (rg1, Australia East)
근접 배치 그룹: proximity2 (rg2, Australia Central)
근접 배치 그룹: proximity3 (rg1, Australia East)

vmss1에 대한 근접 배치 그룹을 구성해야 합니다. 어떤 근접 배치 그룹을 사용해야 할까요?

보기:

A. proximity1 만

B. proximity2 만

C. proximity1 및 proximity3 만

D. proximity1, proximity2 및 proximity3

해설:

이 문제는 Azure에서 **근접 배치 그룹(Proximity Placement Group, PPG)**을 설정할 때의 호환 조건을 묻고 있습니다. 핵심은 위치(Location) 일치 여부입니다. 리소스 그룹은 중요하지 않습니다.

✅ 문제 조건 정리

📌 vmss1 정보:

위치: Australia Central
리소스 그룹: rg2

📌 근접 배치 그룹 목록:

이름	리소스	그룹 위치
proximity1	rg1	Australia East
proximity2	rg2	Australia Central
proximity3	rg1	Australia East

🔍 조건 분석

Azure에서 VM 또는 VMSS는 자신과 동일한 위치(region)에 있는 PPG만 사용 가능합니다.

✅ proximity2: 같은 위치 (Australia Central) → 사용 가능
❌ proximity1, proximity3: 위치 불일치 (Australia East) → 사용 불가

📌 리소스 그룹(rg1, rg2)은 중요하지 않음. **중요한 건 오직 위치(Location)**입니다.

✅ 정답

B. proximity2 만

가상 머신 확장 집합 (Virtual Machine Scale Set, VMSS): 동일한 구성에서 여러 개의 가상 머신을 자동으로 배포하고 관리할 수 있도록 하는 서비스입니다.
근접 배치 그룹 (Proximity Placement Group, PPG): Azure 컴퓨팅 리소스(예: 가상 머신)를 물리적으로 가까운 위치에 배치하여 네트워크 지연 시간을 줄이는 데 사용되는 논리적 그룹입니다. 마치 여러 대의 서버를 같은 방에 배치하는 것과 같습니다.
지역 (Location/Region): Azure 데이터 센터가 위치한 지리적 영역입니다.
제한 사항: 근접 배치 그룹은 동일한 지역 내의 리소스에만 적용할 수 있습니다.

정답: B (가상 머신 확장 집합 vmss1이 Australia Central 지역에 있으므로, 동일한 지역에 있는 근접 배치 그룹 proximity2만 사용할 수 있습니다. proximity1은 rg1에 속하지만 위치는 Australia Central이고, proximity3은 Australia East에 있으므로 vmss1과 동일한 지역이 아닙니다.)

문제 142

Azure 구독에 Azure 파일 공유가 있습니다.

server1이라는 Windows Server 2016을 실행하는 온-프레미스 서버가 있습니다.

Azure 파일 공유와 서버 간에 Azure File Sync를 설정하려고 합니다.

Azure 구독에서 어떤 두 가지 작업을 수행해야 할까요?

보기:

A. 서버 등록 실행

B. 스토리지 동기화 서비스 만들기

C. Azure File Sync 에이전트 설치

D. 동기화 그룹 만들기

해설:

이 문제는 Azure File Sync를 설정하기 위한 Azure 측에서 필요한 두 가지 작업을 묻고 있습니다. 즉, Azure 구독 내에서 수행해야 하는 단계를 정확히 식별해야 합니다.

🎯 핵심 목표:

온-프레미스 서버(server1)와 Azure 파일 공유를 Azure File Sync를 통해 연결 설정하는 것.

🔧 Azure File Sync 구성 절차 요약

Azure File Sync를 제대로 구성하려면 다음 순서로 작업이 이루어져야 합니다.

✅ 1. Azure에서 수행해야 하는 작업

작업	설명	필수 여부
스토리지 동기화 서비스 만들기	Azure에서 File Sync 리소스를 만들기 위한 컨테이너 역할	✅ 필수
동기화 그룹 만들기	Azure 파일 공유 ↔ 온-프레미스 폴더 간의 동기화 논리 연결	✅ 필수

✅ 온-프레미스에서 수행해야 하는 작업 (문제에서 묻지 않음)

작업	설명
Azure File Sync 에이전트 설치	온-프레미스 서버에 Sync 기능 제공
서버 등록 실행	서버를 Azure에 등록하여 동기화 대상으로 설정

✨ 따라서, Azure 구독 내에서 수행해야 할 작업은:

✅ 정답:

B. 스토리지 동기화 서비스 만들기
D. 동기화 그룹 만들기

❌ 오답 해설:

A. 서버 등록 실행 → 온-프레미스 서버에서 수행
C. Azure File Sync 에이전트 설치 → 온-프레미스에서 수행

✅ 정답:

B, D

Azure Files: 클라우드에서 접근 가능한 파일 공유를 제공하는 Azure 서비스입니다.
온-프레미스 서버 (On-Premise Server): 클라우드 환경이 아닌 자체 데이터 센터나 서버실에 있는 서버입니다.
Azure File Sync: 온-프레미스 서버와 Azure 파일 공유 간에 파일을 동기화하는 서비스입니다.
Azure 구독 (Azure Subscription): Azure 서비스를 사용하기 위한 계정입니다.
서버 등록 (Server Registration): 온-프레미스 서버를 스토리지 동기화 서비스에 연결하는 과정입니다. 이 작업은 온-프레미스 서버에서 Azure File Sync 에이전트를 설치한 후 수행됩니다.
스토리지 동기화 서비스 (Storage Sync Service): 온-프레미스 서버와 Azure 파일 공유 간의 동기화를 관리하는 Azure 서비스입니다. 먼저 Azure 구독에 이 서비스를 만들어야 합니다.
Azure File Sync 에이전트: 온-프레미스 서버에 설치되어 동기화 작업을 수행하는 소프트웨어입니다. 이 작업은 Azure 구독이 아닌 온-프레미스 서버에서 수행됩니다.
동기화 그룹 (Sync Group): 동기화할 서버 엔드포인트와 클라우드 엔드포인트(Azure 파일 공유)를 정의하는 논리적 그룹입니다. 스토리지 동기화 서비스를 만든 후 이 그룹을 만들어야 합니다.

정답: B (스토리지 동기화 서비스 만들기) 및 D (동기화 그룹 만들기)

(설명: Azure File Sync를 설정하려면 먼저 Azure 구독에 스토리지 동기화 서비스를 만들고, 동기화할 파일 공유와 서버를 연결하는 동기화 그룹을 만들어야 합니다. 서버 등록 및 에이전트 설치는 온-프레미스 서버에서 수행되는 작업입니다.)

문제 143

cotoso.com이라는 Microsoft Entra ID 테넌트에 다음과 같은 사용자가 있습니다.

user1 (Member, group1 소속)
user2 (Guest, group1 소속)
user3 (Member, group 소속 없음, group1 소유자)
userA (Member, group2 소속)
userB (Guest, group2 소속)

group2는 group1의 멤버입니다. 다음 화면의 그림과 같은 Review1이라는 액세스 검토를 구성합니다. 다음 각 설명이 참인지 거짓인지 선택하세요.

user3은 userA에 대한 액세스 검토를 수행할 수 있습니다.
user3은 userB에 대한 액세스 검토를 수행할 수 있습니다.
user3은 user1에 대한 액세스 검토를 수행할 수 있습니다.

(그림 설명: review1 액세스 검토 구성)

이름: Review1
시작: 2018-11-22(빈도 : 1번)
End: 2018-11-22
User to review: 그룹의 멤버들
범위: 게스트 사용자만
검토자: 그룹 소유자 (group1)
링크 프로그램 : Default program(Upon completion settings)

해설:

이 문제는 **Microsoft Entra ID(구 Azure AD)**에서 액세스 검토(Access Review) 기능과 그 설정 범위, 그리고 권한 위임 방식을 정확히 이해해야 풀 수 있는 시나리오형 문제입니다.

🔍 기본 시나리오 정리

🎯 Access Review1 설정

검토 대상(User to review): 그룹의 멤버들
범위(Scope): 게스트 사용자만
검토자(Reviewers): group1의 소유자 (즉, user3)
검토 대상 그룹: group1

👤 사용자 구조 분석

사용자 유형 group1 소속 group2 소속 group1 소유자 메모

user1	Member	✅	❌	❌	일반 멤버
user2	Guest	✅	❌	❌	✅ 범위 대상
user3	Member	❌	❌	✅	✅ 검토자
userA	Member	❌	✅	❌	간접 멤버 (group2)
userB	Guest	❌	✅	❌	✅ 범위 대상 (group2 소속)
group2	그룹	✅ (group1 멤버)	N/A	❌	중첩 그룹

📌 중요한 개념:

**중첩 그룹(group2가 group1의 멤버)**이라면, group2의 멤버도 group1의 멤버로 간주됨 (Access Review의 범위에 포함됨)
하지만 "게스트 사용자만" 범위 설정이므로, Guest 사용자만 리뷰 대상

🔍 각 설명 평가

✅ 1. user3은 userA에 대한 액세스 검토를 수행할 수 있습니다.

userA: Member, group2 멤버 → 간접적으로 group1에 포함됨
그러나 Member라서 검토 대상이 아님 (게스트만이 대상)
👉 ❌ 거짓

✅ 2. user3은 userB에 대한 액세스 검토를 수행할 수 있습니다.

userB: Guest, group2 멤버 → group2는 group1에 포함됨 → 간접 포함
검토 범위: 게스트 사용자만 → ✅ 대상
검토자: group1 소유자 (user3) → ✅ 권한 있음
👉 ✅ 참

✅ 3. user3은 user1에 대한 액세스 검토를 수행할 수 있습니다.

user1: Member, group1 직접 멤버
검토 범위: 게스트 사용자만 → ❌ 해당 안 됨
👉 ❌ 거짓

✅ 정답 요약:

설명 참/거짓

user3은 userA에 대한 액세스 검토를 수행할 수 있습니다.	❌ 거짓
user3은 userB에 대한 액세스 검토를 수행할 수 있습니다.	✅ 참
user3은 user1에 대한 액세스 검토를 수행할 수 있습니다.	❌ 거짓

Microsoft Entra ID: 클라우드 기반의 ID 및 접근 관리 서비스입니다. (이전 Azure Active Directory)
테넌트 (Tenant): 조직을 위한 Entra ID의 독립적인 인스턴스입니다.
사용자 (User): Entra ID에서 관리하는 개인 계정입니다. 멤버 사용자는 조직의 구성원이고, 게스트 사용자는 외부에서 초대된 사용자입니다.
그룹 (Group): 사용자, 장치 또는 기타 Entra ID 개체의 모음입니다.
액세스 검토 (Access Review): 누가 어떤 리소스에 어떤 접근 권한을 가지고 있는지 정기적으로 확인하고 필요한 경우 권한을 제거하는 기능입니다.
범위 (Scope): 액세스 검토를 수행할 대상 사용자 또는 그룹의 범위입니다.
검토자 (Reviewer): 액세스 권한을 검토하고 유지 또는 제거 결정을 내리는 사용자입니다.
그룹 소유자 (Group Owner): 해당 그룹을 관리하고 구성원을 변경할 수 있는 사용자입니다.

정답:

user3은 userA에 대한 액세스 검토를 수행할 수 있습니까? 아니요. (액세스 검토의 범위가 '게스트 사용자만'이고, userA는 '멤버' 유형 사용자입니다.)
user3은 userB에 대한 액세스 검토를 수행할 수 있습니까? 예. (액세스 검토의 범위가 '게스트 사용자만'이고, userB는 '게스트' 유형 사용자이며, user3은 group1의 소유자이므로 검토자입니다.)
user3은 user1에 대한 액세스 검토를 수행할 수 있습니까? 아니요. (액세스 검토의 범위가 '게스트 사용자만'이고, user1은 '멤버' 유형 사용자입니다.)

문제 144

subscription1이라는 Azure 구독에 vm1이라는 Azure 가상 머신이 있습니다. vm1은 rg1이라는 리소스 그룹에 있습니다. vm1은 rg1에 리소스를 배포하는 데 사용될 서비스를 실행합니다. vm1의 ID를 사용하여 vm1에서 실행되는 서비스가 rg1의 리소스를 관리할 수 있도록 해야 합니다. 가장 먼저 무엇을 해야 할까요?

보기:

A. Azure Portal에서 rg1의 액세스 제어(IAM) 설정 수정

B. Azure Portal에서 rg1의 정책 설정 수정

C. Azure Portal에서 vm1의 관리 ID 설정 수정

D. Azure Portal에서 vm1의 액세스 제어 설정 수정

해설:

이 시나리오의 핵심은 Azure VM(vm1)이 실행하는 서비스가 리소스 그룹(rg1)의 리소스를 관리할 수 있도록 vm1의 ID를 활용하는 것입니다.

✅ 목적 요약

vm1의 Managed Identity를 사용해서
→ rg1의 리소스를 배포 및 관리
→ 즉, vm1의 ID에 적절한 RBAC 권한 부여

🔍 문제의 키포인트

질문은 "가장 먼저 무엇을 해야 하나요?"입니다.

이 질문에 대한 핵심은:

vm1의 ID를 사용하고자 한다면, 먼저 ID가 존재해야 합니다.

🧩 보기 분석

보기 의미 우선순위 판단

A. rg1의 IAM 설정 수정	권한 부여 작업, ID가 이미 있어야 가능	2차 작업	❌
B. rg1의 정책 설정 수정	정책은 제한과 규칙 설정용, RBAC과 무관	해당 없음	❌
C. vm1의 관리 ID 설정 수정	✅ ID 자체를 활성화함, 가장 먼저 해야 할 일	1차 작업	✅ 정답
D. vm1의 액세스 제어 설정 수정	vm1에 대한 권한 설정이지, vm1이 다른 리소스를 제어하는 데는 무관	해당 없음	❌

✅ 정답: C. Azure Portal에서 vm1의 관리 ID 설정 수정

🔧 전체 흐름 정리 (단계별)

vm1의 시스템 할당 Managed Identity를 활성화
→ 이 단계에서 vm1은 Azure 내에서 식별 가능한 보안 ID를 가지게 됨
rg1의 IAM에서 해당 ID에 필요한 권한(Role)을 할당
→ 예: Contributor, Reader, 특정 리소스에 대한 커스텀 역할 등
vm1에서 실행되는 앱/스크립트 등에서 해당 ID로 인증하여 리소스 접근

Azure 가상 머신 (Azure Virtual Machine, VM): 클라우드에서 실행되는 가상의 컴퓨터입니다.
리소스 그룹 (Resource Group): 관련된 Azure 리소스들을 논리적으로 묶어 놓은 컨테이너입니다.
관리 ID (Managed Identity): Azure 서비스가 Azure Active Directory (현재 Microsoft Entra ID)에서 자동으로 관리되는 ID를 얻어 Azure AD 인증을 지원하는 다른 서비스에 안전하게 액세스할 수 있도록 하는 기능입니다. 비밀번호나 자격 증명을 코드에 저장할 필요가 없습니다. 마치 Azure 서비스에게 부여된 디지털 신분증과 같습니다.
액세스 제어 (IAM - Identity and Access Management): 누가 어떤 Azure 리소스에 대해 어떤 작업을 수행할 수 있는지 관리하는 Azure 서비스입니다.
정책 (Policy): Azure 리소스에 대한 규칙을 정의하고 적용하여 규정 준수를 유지하고 리소스를 관리하는 서비스입니다.

정답: C (Azure Portal에서 vm1의 관리 ID 설정을 수정하여 관리 ID를 활성화해야 합니다.

그런 다음 해당 관리 ID에 rg1에 대한 리소스를 관리할 수 있는 적절한 역할(예: Contributor)을 할당해야 합니다.)

문제 145

admin1이라는 Azure Active Directory 사용자가

Azure 구독에 대한 트래픽 분석을 활성화하는 데 필요한 역할을 할당받았는지 확인해야 합니다.

제공하는 솔루션은 admin1에게 구독 수준에서 Traffic Manager Contributor 역할을 할당하는 것입니다.

이 솔루션이 목표를 충족합니까?

해설:

이 문제는 admin1 사용자가 "Azure 구독의 트래픽 분석을 활성화"할 수 있는지 확인하는 것입니다.
핵심은 "Traffic Manager Contributor 역할이 이 작업을 수행하기에 적절한 권한을 부여하는가?"입니다.

🔍 트래픽 분석(traffic analytics)이란?

Azure에서 **트래픽 분석(Traffic Analytics)**은 Network Watcher의 기능입니다.
NSG(네트워크 보안 그룹) 흐름 로그를 기반으로 트래픽 흐름을 시각화하고 분석합니다.

따라서 트래픽 분석을 활성화하려면:

Network Watcher의 구성
NSG 흐름 로그 활성화
로그를 저장할 스토리지 계정 설정
트래픽 분석 기능을 켜는 권한

🎯 Traffic Manager Contributor 역할?

역할 설명

Traffic Manager Contributor	Azure Traffic Manager 리소스에 대한 관리 권한 제공 (라우팅, 엔드포인트 설정 등)
❌ 관련 없음	Traffic Analytics (Network Watcher 기반) 기능과는 무관함

🔺 **"Traffic Manager"**는 DNS 기반 로드 밸런싱 서비스고,
🔻 **"Traffic Analytics"**는 NSG 로그 기반 네트워크 분석 도구입니다. 전혀 다른 서비스입니다.

✅ 필요한 권한은?

Network Contributor 또는 그 이상(Owner, Contributor 등)이 있어야 합니다.

역할 트래픽 분석 활성화 가능 여부

Network Contributor	✅ 가능
Contributor	✅ 가능
Traffic Manager Contributor	❌ 불가능 (완전히 다른 서비스)

🧩 결론

❌ 이 솔루션은 목표를 충족하지 못합니다.

admin1에게 "Network Contributor" 역할을 구독 수준 또는 Network Watcher 리소스에 부여해야 합니다.

Azure Active Directory (Azure AD): 클라우드 기반의 ID 및 접근 관리 서비스입니다. (현재는 Microsoft Entra ID로 이름이 변경되었습니다.)
Azure 구독 (Azure Subscription): Azure 서비스를 사용하기 위한 계정입니다.
트래픽 분석 (Traffic Analytics): Azure Network Watcher의 기능으로, Azure 네트워크 트래픽의 흐름에 대한 인사이트를 제공합니다. 네트워크 보안, 성능 모니터링 및 용량 계획에 유용합니다.
Traffic Manager: DNS 기반의 트래픽 라우팅 서비스로, 전역적으로 트래픽을 분산하는 데 사용됩니다. 트래픽 분석과는 직접적인 관련이 적습니다.
Traffic Manager Contributor 역할: Azure Traffic Manager 리소스를 관리할 수 있는 권한을 제공하는 역할입니다.
Network Contributor 역할: 네트워크 리소스를 관리할 수 있는 권한을 제공하는 역할입니다. 트래픽 분석을 활성화하는 데 필요한 권한을 포함할 수 있습니다.
Monitoring Contributor 역할: Azure Monitor 서비스를 읽고 쓰고 관리할 수 있는 권한을 제공하는 역할입니다. 트래픽 분석 구성을 위한 권한을 포함할 수 있습니다.

정답: 아니요. (Traffic Manager Contributor 역할은 트래픽 분석 활성화에 필요한 권한을 제공하지 않습니다. 트래픽 분석을 활성화하려면 일반적으로 Network Contributor 또는 Monitoring Contributor 역할과 같은 네트워크 및 모니터링 관련 역할이 필요합니다.)

문제 146

vm1과 vm2라는 두 개의 Azure 가상 머신과 rsv1과 rsv2라는 두 개의 Recovery Services 자격 증명 모음이 있습니다.

vm1은 rsv1에 백업되어 있으며, vm1을 rsv2에 백업해야 합니다. 가장 먼저 무엇을 해야 할까요?

보기:

A. rsv1 블레이드에서 백업 작업 클릭 및 vm1 작업 내보내기

B. rsv2 블레이드에서 백업 클릭, 백업 블레이드에서 가상 머신 백업 선택 후 백업 클릭

C. rsv1 블레이드에서 백업 항목 클릭 및 vm1 백업 중지

D. vm1 블레이드에서 재해 복구 클릭, 복제 설정 클릭 후 복구 서비스 자격 증명 모음으로 rsv2 선택

해설:

이 시나리오에서 **vm1은 이미 rsv1(Recovery Services Vault 1)**에 백업되어 있고,
이제 rsv2에 백업을 구성해야 합니다.
Azure에서는 하나의 VM은 동시에 단 하나의 자격 증명 모음(Vault)에만 백업될 수 있습니다.

✅ 목표

vm1의 백업을 rsv1 → rsv2로 이전
즉, 기존 백업 연결 해제 후 새로 백업 구성

🧩 보기 분석

보기	설명	적절성
A. rsv1 블레이드에서 백업 작업 클릭 및 vm1 작업 내보내기	Azure에서는 백업 설정을 “내보내는” 기능이 없음	❌
B. rsv2 블레이드에서 백업 클릭, 가상 머신 백업 선택 후 백업 클릭	기존 백업 연결 해제 없이 새 백업 구성은 불가 → 오류 발생	❌
C. rsv1 블레이드에서 백업 항목 클릭 및 vm1 백업 중지	✅ 가장 먼저 해야 할 작업. 백업 연결 해제 (정지) 필요	✅
D. vm1 블레이드에서 재해 복구 클릭…	이건 Azure Site Recovery(복제/재해 복구) 관련, 백업과 무관	❌

✅ 정답: C. rsv1 블레이드에서 백업 항목 클릭 및 vm1 백업 중지

이후 작업 흐름

rsv1에서 vm1의 백업 중지 (옵션에 따라 스냅샷 삭제 여부 선택)
rsv2에서 백업 구성 시작 → 가상 머신 선택 → 정책 설정 후 백업 구성

⚠ 주의사항

백업을 중지하면 기존 백업 데이터가 삭제될 수 있으므로 주의해야 합니다.
완전히 삭제하지 않고 보존하려면, 중지 시 “데이터 유지” 옵션 선택 가능

Azure 가상 머신 (Azure Virtual Machine, VM): 클라우드에서 실행되는 가상의 컴퓨터입니다.
Recovery Services 자격 증명 모음 (Recovery Services Vault): Azure Backup 및 Azure Site Recovery와 같은 데이터 보호 서비스를 위한 중앙 집중식 관리 콘솔입니다. 백업 데이터 및 복제 구성이 저장됩니다. 마치 안전 금고와 같습니다.
Azure Backup: Azure VM, Azure Files, SQL Server 등을 백업하고 복원하는 Azure 서비스입니다.
백업 작업 (Backup Job): 특정 시점에 데이터를 백업하는 프로세스입니다.
백업 항목 (Backup Items): 자격 증명 모음에 등록되어 백업이 구성된 리소스(예: 가상 머신)입니다.
재해 복구 (Disaster Recovery): 자연 재해 또는 시스템 장애 발생 시 데이터 및 애플리케이션을 복구하는 계획 및 프로세스입니다. Azure Site Recovery를 사용하여 구현할 수 있습니다.
복제 설정 (Replication Settings): Azure Site Recovery를 사용하여 VM을 다른 Azure 지역으로 복제하는 설정을 구성하는 것입니다.

정답: C (하나의 가상 머신은 한 번에 하나의 Recovery Services 자격 증명 모음에만 백업할 수 있습니다. 따라서 vm1을 rsv2에 백업하려면 먼저 rsv1에 있는 vm1의 기존 백업을 중지해야 합니다.)

문제 147

Azure 구독에 다음과 같은 리소스가 있습니다.

storage1 (스토리지 계정)
container1 (Blob 컨테이너)
table1 (스토리지 테이블)

다음 작업을 수행해야 합니다.

새 스토리지 계정 만들기
container1에 Blob 업로드 및 추가
storage1에 파일 공유 만들기
table1에 데이터 추가

어떤 작업을 Azure Storage Explorer를 사용하여 수행할 수 있을까요?

보기:

A. 1번 및 3번 만

B. 1번, 2번 및 3번 만

C. 1번, 3번 및 4번 만

D. 2번, 3번 및 4번 만

E. 1번, 2번, 3번 및 4번

해설:

이 문제의 핵심은 Azure Storage Explorer의 기능 범위를 정확히 이해하는 것입니다.

✅ 작업별 수행 가능 여부 in Azure Storage Explorer

작업 번호 작업 설명 Storage Explorer에서 가능 여부 이유

1	새 스토리지 계정 만들기	❌	Storage Explorer는 기존 스토리지 계정만 탐색/관리 가능. 새 계정 생성은 불가
2	container1에 Blob 업로드 및 추가	✅	완벽히 지원. 드래그앤드롭으로 업로드도 가능
3	storage1에 파일 공유 만들기	✅	File Shares 생성 및 관리 가능
4	table1에 데이터 추가	✅	Table Storage에 데이터 조회 및 삽입 가능

🧩 보기 검토

보기 내용 적절성

A. 1번 및 3번 만	1번 ❌ → 탈락	❌
B. 1번, 2번 및 3번 만	1번 ❌ → 탈락	❌
C. 1번, 3번 및 4번 만	1번 ❌ → 탈락	❌
D. 2번, 3번 및 4번 만	2, 3, 4 모두 ✅	✅ 정답
E. 1번, 2번, 3번 및 4번	1번 ❌ → 탈락	❌

✅ 정답: D. 2번, 3번 및 4번 만

🔎 정리

Azure Storage Explorer는 스토리지 계정 생성 불가, 하지만 Blob, File Share, Table Storage의 데이터 수준 작업은 매우 강력하게 지원합니다.

Azure Storage Explorer: Azure Storage 데이터를 시각적으로 탐색하고 관리할 수 있는 무료 독립 실행형 앱입니다. 마치 클라우드 저장소의 파일 탐색기와 같습니다.
스토리지 계정 (Storage Account): Azure에서 데이터를 저장하는 기본적인 단위입니다.
Blob 컨테이너 (Blob Container): Blob Storage 내에서 비정형 데이터를 저장하는 폴더와 같은 개념입니다.
Blob (Binary Large Object): 텍스트, 이미지, 비디오 등 대용량 비정형 데이터입니다.
파일 공유 (File Share): 클라우드에서 접근 가능한 파일 공유를 제공하는 Azure Files 서비스입니다.
스토리지 테이블 (Storage Table): NoSQL 키-값 데이터 저장소인 Azure Table Storage 서비스입니다.

정답: D (Azure Storage Explorer를 사용하면 기존 스토리지 계정에 연결하여 Blob 컨테이너의 데이터 업로드/다운로드, 파일 공유 생성 및 관리, 스토리지 테이블의 데이터 추가/편집 등의 작업을 수행할 수 있지만, Azure Storage Explorer 자체에서 새 스토리지 계정을 만들 수는 없습니다.)

문제 148

Sub1, Sub2, Sub3라는 세 개의 Azure 구독이 Microsoft Entra ID 테넌트에 연결되어 있습니다. 테넌트에는 user1이라는 사용자, group1이라는 보안 그룹, mg1이라는 관리 그룹이 있습니다. user1은 group1의 멤버입니다. Sub1과 Sub2는 mg1의 멤버입니다. Sub1에는 RG1이라는 리소스 그룹이 있으며, RG1에는 5개의 Azure Functions가 있습니다. mg1에 대해 다음과 같은 역할 할당을 만듭니다.

group1: Reader 역할
user1: User Access Administrator 역할

또한 user1에게 Sub1과 Sub2에 대한 Virtual Machine Contributor 역할을 할당합니다. 다음 각 설명이 참인지 거짓인지 선택하세요.

user1은 mg1의 User Access Administrator로서 rg1에 대한 Owner 역할을 할당할 수 있습니다.
group1 멤버는 Azure Functions 구성을 검토할 수 있습니다.
user1은 새 리소스 그룹을 만들고 새 그룹에 가상 머신을 배포할 수 있습니다.

해설:

이 시나리오의 핵심은 역할 상속의 계층 구조, 각 역할의 기능 범위, 그리고 사용자/그룹의 역할 연결 방식을 정확히 파악하는 것입니다.

🔍 전제 요약

user1은 group1의 멤버
group1은 mg1에 Reader 역할
user1은 mg1에 User Access Administrator 역할
user1은 Sub1, Sub2에 Virtual Machine Contributor 역할
Sub1 → RG1 → Azure Functions 5개 존재

✅ 설명별 분석

🔹 설명 1: user1은 mg1의 User Access Administrator로서 rg1에 대한 Owner 역할을 할당할 수 있습니다.

User Access Administrator 역할은 **역할을 위임할 수 있는 권한(RBAC 설정 가능)**만을 부여하며, 직접적인 리소스 제어 권한은 없음.
mg1에 할당된 경우, 그 하위 리소스(Sub1 → RG1)에 대해서도 역할 할당이 가능.
→ 즉, user1은 rg1에 대해 Owner 역할을 할당할 수 있음

✅ 참

🔹 설명 2: group1 멤버는 Azure Functions 구성을 검토할 수 있습니다.

group1은 mg1에 Reader 역할이 있음 → Reader 역할은 모든 하위 리소스까지 읽기 권한을 상속
RG1 및 Azure Functions도 Reader로 접근 가능 → 구성 확인 가능

✅ 참

🔹 설명 3: user1은 새 리소스 그룹을 만들고 새 그룹에 가상 머신을 배포할 수 있습니다.

리소스 그룹 만들기 = 구독 수준의 Contributor 권한 필요
user1은 Sub1과 Sub2에 "Virtual Machine Contributor" 역할만 있음
- 이 역할은 VM 관리에는 충분하지만, 리소스 그룹 생성 권한은 없음
- 공식 Docs – Virtual Machine Contributor: "Can manage virtual machines, but not the virtual network or storage account to which they are connected. Cannot manage availability sets or resource groups."

❌ 거짓

✅ 정답 요약

설명 정답 이유 요약

user1은 rg1에 Owner 역할 할당 가능	✅ 참	User Access Administrator로 mg1 하위 자원에 역할 할당 가능
group1 멤버는 Azure Functions 구성 검토 가능	✅ 참	Reader 역할은 읽기 권한 포함
user1은 새 리소스 그룹 생성 및 VM 배포 가능	❌ 거짓	VM 배포는 가능하지만, 리소스 그룹 생성 권한 없음

Azure 구독 (Azure Subscription): Azure 서비스를 사용하기 위한 계정입니다.
Microsoft Entra ID: 클라우드 기반의 ID 및 접근 관리 서비스입니다. (이전 Azure Active Directory)
관리 그룹 (Management Group): Azure 구독을 논리적으로 그룹화하여 정책 및 접근 제어를 계층적으로 관리하는 데 사용됩니다.
보안 그룹 (Security Group): 사용자들을 모아서 권한을 쉽게 할당하고 관리하기 위한 그룹입니다.
역할 할당 (Role Assignment): 특정 보안 주체에게 특정 범위에 대한 특정 역할을 부여하는 것입니다.
Reader 역할: Azure 리소스를 볼 수 있는 권한을 제공합니다.
User Access Administrator 역할: Azure 리소스에 대한 사용자 액세스를 관리할 수 있는 권한을 제공합니다 (역할 할당 생성 및 관리 포함). 관리 그룹 범위에 할당되면 해당 관리 그룹 내의 모든 구독 및 리소스에 대한 액세스 관리가 가능합니다.
Virtual Machine Contributor 역할: 가상 머신을 만들고 관리할 수 있는 권한을 제공합니다. 구독 범위에 할당되면 해당 구독 내에서 가상 머신 관련 작업을 수행할 수 있습니다.
Owner 역할: Azure 리소스에 대한 모든 권한을 가지며, 다른 사용자에게 권한을 위임할 수도 있는 역할입니다.
Azure Functions: 서버리스 컴퓨팅 서비스로, 이벤트 트리거에 따라 코드를 실행할 수 있습니다.
리소스 그룹 (Resource Group): 관련된 Azure 리소스들을 논리적으로 묶어 놓은 컨테이너입니다.

정답:

user1은 mg1의 User Access Administrator로서 rg1에 대한 Owner 역할을 할당할 수 있습니까? 예. (User Access Administrator 역할은 할당된 범위(mg1) 내의 모든 리소스에 대한 액세스 관리를 허용합니다. rg1은 mg1 내에 있으므로 user1은 rg1에 대한 역할을 할당할 수 있습니다.)
group1 멤버는 Azure Functions 구성을 검토할 수 있습니까? 예. (group1은 mg1에 대한 Reader 역할을 가지고 있으므로, mg1 내의 모든 리소스(RG1의 Azure Functions 포함)의 구성을 볼 수 있습니다.)
user1은 새 리소스 그룹을 만들고 새 그룹에 가상 머신을 배포할 수 있습니까? 아니요. (Virtual Machine Contributor 역할은 가상 머신 관리 권한만 제공하며, 새 리소스 그룹을 만들 권한은 포함하지 않습니다.)

문제 149

subscription1이라는 Azure 구독에 vnet1과 vnet2라는 두 개의 Azure 가상 네트워크가 있습니다.

vnet1에는 정적 라우팅을 사용하는 VPN gw1이라는 VPN 게이트웨이가 있습니다.

온-프레미스 네트워크와 vnet1 간에 사이트 간 VPN 연결이 있습니다.

Windows 10을 실행하는 client1이라는 컴퓨터에서 vnet1에 대한 지점 대 사이트 VPN 연결을 구성합니다.

vnet1과 vnet2 간에 가상 네트워크 피어링을 구성합니다.

온-프레미스 네트워크에서 vnet2에 연결할 수 있는지 확인했지만, client1은 vnet2에 연결할 수 없습니다.

client1을 vnet2에 연결할 수 있도록 해야 합니다.

어떻게 해야 할까요?

보기:

A. vnet2에 대한 게이트웨이 전송 허용 선택

B. client1에서 VPN 클라이언트 구성 패키지 다운로드 및 재설치

C. VPN gw1에서 BGP 활성화

D. vnet1에서 게이트웨이 전송 허용 선택

해설:

이 문제는 지점 대 사이트 VPN 클라이언트(client1)가 vnet1에는 연결할 수 있지만 vnet2에는 연결할 수 없는 상황입니다. 그러나 온-프레미스 네트워크는 vnet2에 정상적으로 접근할 수 있습니다.

✅ 시나리오 구조 요약

vnet1:
- VPN 게이트웨이(gw1) 있음 (정적 라우팅 사용)
- 온-프레미스 연결 및 client1의 VPN 연결이 모두 여기에 설정됨
vnet2:
- vnet1과 피어링(Peering) 되어 있음
client1:
- vnet1과 지점 대 사이트 VPN 연결은 정상
- 그러나 vnet2에는 연결 불가

🔍 피어링과 게이트웨이 전송의 원리

Azure의 가상 네트워크 피어링에서 "게이트웨이 전송 허용(Use Remote Gateway)" 옵션은 다음과 같은 상황에서 사용됩니다:

vnet1에 VPN 게이트웨이가 있고
vnet2는 자체 게이트웨이가 없으며
vnet2의 트래픽을 vnet1의 게이트웨이로 전달하고자 할 때

즉, vnet2에서 "게이트웨이 전송 허용"을 활성화해야 client1에서 온 VPN 트래픽이 vnet2로 흐를 수 있습니다.

🔎 보기별 분석

보기	의미	적합성	판단
A. vnet2에 대한 게이트웨이 전송 허용 선택	🔑 vnet2 → vnet1의 게이트웨이 사용 허용	✅ 정답	✔
B. VPN 클라이언트 구성 패키지 재설치	구성 변경 시 필요할 수 있으나 현재는 설정 문제 아님	❌ 부적합	✘
C. gw1에서 BGP 활성화	BGP는 경로 자동 분배용, 현재는 정적 라우팅 사용	❌ 관련 없음	✘
D. vnet1에서 게이트웨이 전송 허용 선택	vnet1은 이미 게이트웨이 보유자 → 의미 없음	❌ 부적합	✘

✅ 정답: A. vnet2에 대한 게이트웨이 전송 허용 선택

🔧 시각적 구조 요약

[Client1] --VPN--> [gw1 (vnet1)] <--Peering--> [vnet2]
                       ▲                          ▲
                 게이트웨이 있음        게이트웨이 없음 (→ vnet1 사용하려면 Gateway Transit 필요)

가상 네트워크 (Virtual Network, VNet): Azure에서 생성하는 사설 네트워크입니다.
VPN 게이트웨이 (VPN Gateway): Azure 가상 네트워크와 온-프레미스 네트워크 간의 VPN 연결을 만드는 데 사용되는 가상 네트워크 게이트웨이입니다.
정적 라우팅 (Static Routing): 네트워크 경로를 수동으로 구성하는 방식입니다.
사이트 간 VPN (Site-to-Site VPN): 온-프레미스 네트워크와 Azure 가상 네트워크 간에 영구적인 보안 연결을 만드는 것입니다.
지점 대 사이트 VPN (Point-to-Site VPN): 개별 클라이언트 컴퓨터에서 Azure 가상 네트워크로 보안 연결을 만드는 것입니다.
가상 네트워크 피어링 (Virtual Network Peering): 서로 다른 가상 네트워크 간에 사설 IP 주소를 사용하여 연결을 생성하여 마치 하나의 가상 네트워크처럼 통신할 수 있도록 하는 Azure 기능입니다.
게이트웨이 전송 허용 (Allow Gateway Transit): 가상 네트워크 피어링 연결 시 한쪽 가상 네트워크의 VPN 게이트웨이를 통해 다른 피어링된 가상 네트워크로 트래픽을 라우팅할 수 있도록 하는 설정입니다.
BGP (Border Gateway Protocol): 네트워크 간의 라우팅 정보를 교환하는 표준 라우팅 프로토콜입니다. VPN 연결에서 동적 라우팅을 위해 사용될 수 있습니다.
VPN 클라이언트 구성 패키지: 지점 대 사이트 VPN 연결을 설정하는 데 필요한 인증서, VPN 서버 주소 등의 정보가 포함된 파일입니다.

정답: B (가상 네트워크 토폴로지가 변경(vnet1과 vnet2 간 피어링 추가)되었으므로, 지점 대 사이트 VPN 클라이언트의 라우팅 정보가 더 이상 유효하지 않을 수 있습니다. 따라서 client1에서 VPN 클라이언트 구성 패키지를 다시 다운로드하고 설치하여 최신 라우팅 정보를 얻어야 vnet2에 연결할 수 있습니다.)

문제 150

Windows Server 2019를 실행하는 5개의 Azure 가상 머신이 있습니다.

가상 머신은 웹 서버로 구성되어 있습니다.

lb1이라는 Azure Load Balancer는 가상 머신에 대한 부하 분산 서비스를 제공합니다.

방문자가 각 요청에 대해 동일한 웹 서버에서 서비스를 받도록 해야 합니다.

무엇을 구성해야 할까요?

보기:

A. 프로토콜을 UDP로 구성

B. 세션 지속성을 클라이언트 IP 및 프로토콜로 구성

C. 부동 IP 활성화

D. 세션 지속성을 없음으로 구성

해설:

이 시나리오에서 요구하는 것은 다음과 같습니다:

방문자가 각 요청마다 동일한 웹 서버에 연결되도록 한다.

이건 세션 고정(Session Persistence, Affinity) 문제이며,

Azure Load Balancer의 세션 지속성 설정을 조정해야 해결됩니다.

🔍 핵심 목표

웹 서버 5개
Azure Load Balancer (lb1) 사용
같은 클라이언트의 요청을 항상 같은 VM으로 라우팅해야 함

✅ Azure Load Balancer에서 세션 지속성(Session Persistence)

Azure Load Balancer는 다음 옵션을 제공합니다:

세션 지속성	옵션 의미
없음(None)	모든 요청을 무작위(라운드 로빈 등) 방식으로 분산
Client IP	클라이언트 IP 기준으로 고정 라우팅
Client IP 및 프로토콜	클라이언트 IP + 포트/프로토콜까지 고려하여 더 정밀하게 고정

🔎 보기별 분석

보기	설명	적합성	판단
A. 프로토콜을 UDP로 구성	프로토콜은 세션 고정과 무관, 일반적으로 웹 트래픽은 TCP 사용	❌ 부적절	✘
B. 세션 지속성을 클라이언트 IP 및 프로토콜로 구성	✅ 클라이언트가 항상 같은 VM으로 라우팅됨, 가장 정확한 세션 유지	✔ 적합	✅ 정답
C. 부동 IP 활성화	Azure 내부 NAT 사용 시 필요한 설정, 세션 고정과 무관	❌ 부적절	✘
D. 세션 지속성을 없음으로 구성	요청마다 다른 백엔드 VM에 라우팅될 수 있음	❌ 요구사항 불충족	✘

✅ 정답: B. 세션 지속성을 클라이언트 IP 및 프로토콜로 구성

🔁 보충 정보

"Client IP만" 선택해도 대부분의 웹 시나리오에서는 충분하지만,
보안성이나 포트별 구분까지 명확히 하려면 Client IP 및 프로토콜이 더 정밀합니다.

Azure 가상 머신 (Azure Virtual Machine, VM): 클라우드에서 실행되는 가상의 컴퓨터입니다.
웹 서버 (Web Server): 웹 브라우저의 요청을 받아 웹 페이지를 제공하는 서버입니다.
Azure Load Balancer: 들어오는 네트워크 트래픽을 여러 서버에 분산시켜서 서비스의 가용성과 응답성을 높이는 Azure 서비스입니다.
세션 지속성 (Session Persistence) / 연결 고정 (Connection Persistence) / 세션 어피니티 (Session Affinity): 동일한 클라이언트의 모든 요청을 특정 백엔드 서버로 라우팅하는 Load Balancer의 기능입니다. 사용자 세션 정보를 유지해야 하는 애플리케이션에 유용합니다.
UDP (User Datagram Protocol): TCP와 달리 연결 설정 및 오류 확인 과정이 없는 빠른 비연결형 프로토콜입니다. 일반적으로 스트리밍이나 실시간 통신에 사용됩니다. 웹 서버 트래픽은 일반적으로 TCP를 사용합니다.
클라이언트 IP 및 프로토콜 (Client IP and Protocol): 클라이언트의 IP 주소와 사용된 네트워크 프로토콜(예: TCP, UDP)을 기반으로 세션 지속성을 설정하는 방식입니다.
부동 IP (Floating IP) / 직접 서버 반환 (Direct Server Return): Load Balancer를 거치지 않고 백엔드 서버가 클라이언트에 직접 응답할 수 있도록 하는 고급 Load Balancer 구성입니다.
세션 지속성 없음 (None): Load Balancer가 들어오는 각 요청을 가용성이 높은 백엔드 서버로 분산합니다.

정답: B (세션 지속성을 클라이언트 IP 및 프로토콜로 구성하면 동일한 클라이언트 IP 주소와 프로토콜을 사용하는 모든 요청이 세션 기간 동안 동일한 웹 서버로 전달됩니다. 이를 통해 각 방문자는 일관된 경험을 얻을 수 있습니다.)

문제 151

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

mg1 (관리 그룹)
rg1 (리소스 그룹)
vm1 (가상 머신)

admin1이라는 사용자를 만듭니다. admin1을 공동 관리자로 누구에게 추가할 수 있을까요?

보기:

A. rg1

B. mg1

C. sub1

D. vm1

해설:

이 질문에서의 핵심은 admin1 사용자를 공동 관리자로 추가할 수 있는 대상입니다.

Azure에서 공동 관리자(Co-Administrator) 역할은 주로 구독 수준에서 권한을 부여할 수 있으며,

구체적으로 구독 내 리소스에 대한 관리 권한을 부여하는 데 사용됩니다.

각 보기 분석:

보기	설명	적합성	판단
A. rg1	리소스 그룹에 공동 관리자를 추가할 수는 없습니다. 대신 특정 역할(RBAC)을 할당할 수 있습니다.	❌ 부적절	✘
B. mg1	관리 그룹은 구독을 포함하는 상위 구조로, 공동 관리자 역할을 할당할 수는 없습니다.	❌ 부적절	✘
C. sub1	구독 수준에서 공동 관리자를 추가할 수 있습니다. 이는 여러 리소스를 포함한 전체 관리 권한을 부여할 수 있는 곳입니다.	✔ 적합	✅ 정답
D. vm1	개별 가상 머신에 공동 관리자를 추가할 수 없습니다.	❌ 부적절	✘

✅ 정답: C. sub1

🔎 추가 정보:

공동 관리자(Co-Administrator) 역할은 구독 수준에서만 사용되며, Azure 구독 내 모든 리소스에 대한 관리 권한을 부여합니다. 리소스 그룹이나 가상 머신 수준에서는 공동 관리자를 설정할 수 없고, 대신 **역할 기반 액세스 제어(RBAC)**를 통해 역할을 할당해야 합니다.

Azure 구독 (Azure Subscription): Azure 서비스를 사용하기 위한 계정입니다.
관리 그룹 (Management Group): Azure 구독을 논리적으로 그룹화하여 정책 및 접근 제어를 계층적으로 관리하는 데 사용됩니다.
리소스 그룹 (Resource Group): 관련된 Azure 리소스들을 논리적으로 묶어 놓은 컨테이너입니다.
가상 머신 (Virtual Machine, VM): 클라우드에서 실행되는 가상의 컴퓨터입니다.
공동 관리자 (Co-administrator): 클래식 배포 모델에서 구독에 대한 관리 권한을 부여하는 역할입니다. ARM (Azure Resource Manager) 배포 모델에서는 역할 기반 접근 제어(RBAC)를 사용하는 것이 권장됩니다. 공동 관리자는 구독 수준에서 할당됩니다.

정답: C (공동 관리자는 Azure 구독 수준에서만 할당할 수 있습니다.)

문제 152

다음 표와 같은 그룹을 포함하는 Microsoft Entra 테넌트가 있습니다.

Group 1: Security, 라이선스 할당됨
Group 2: Security, 라이선스 할당 안 됨
Group 3: Microsoft 365, 라이선스 할당됨
Group 4: Microsoft 365, 라이선스 할당 안 됨

테넌트에는 다음 표와 같은 사용자가 있습니다.

User 1: 그룹 소속 없음, 라이선스 할당됨
User 2: Group 1 소속, 라이선스 할당 안 됨
User 3: Group 4 소속, 라이선스 할당됨
User 4: 그룹 소속 없음, 라이선스 할당 안 됨

어떤 사용자와 그룹을 삭제할 수 있을까요?

해설:

Microsoft Entra 테넌트에서 그룹과 사용자 삭제 가능성

아래 표와 같이 그룹과 사용자가 구성되어 있습니다.

그룹 목록

그룹유형라이선스 할당

Group 1	Security	할당됨
Group 2	Security	할당 안 됨
Group 3	Microsoft 365	할당됨
Group 4	Microsoft 365	할당 안 됨

사용자 목록

사용자그룹 소속라이선스 할당

User 1	없음	할당됨
User 2	Group 1	할당 안 됨
User 3	Group 4	할당됨
User 4	없음	할당 안 됨

삭제 관련 규칙 요약

라이선스가 할당된 그룹(Group 1, Group 3)은 직접 삭제할 수 없습니다.
→ 그룹에 할당된 라이선스를 먼저 제거해야 삭제가 가능합니다42.
라이선스가 없는 그룹(Group 2, Group 4)은 바로 삭제할 수 있습니다4.
사용자는 라이선스 보유 여부, 그룹 소속 여부와 관계없이 삭제가 가능합니다. 단, 테넌트 삭제 시에는 한 명의 글로벌 관리자만 남기고 모두 삭제해야 합니다13.
그룹 기반 라이선스를 가진 사용자를 삭제하면, 해당 사용자의 라이선스도 함께 제거됩니다25.

적용 결과

삭제 가능한 그룹

Group 2: Security, 라이선스 할당 안 됨 → 바로 삭제 가능
Group 4: Microsoft 365, 라이선스 할당 안 됨 → 바로 삭제 가능

Group 1과 Group 3은 라이선스가 할당되어 있으므로, 라이선스를 먼저 제거해야 삭제할 수 있습니다4.

삭제 가능한 사용자

User 1~4 모두 삭제 가능
(단, 테넌트 전체 삭제가 아니라면, 사용자 삭제 자체는 라이선스 및 그룹 소속과 무관하게 개별적으로 가능함)1 35.

결론

삭제 즉시 가능한 그룹:
- Group 2
- Group 4
삭제 즉시 가능한 사용자:
- User 1
- User 2
- User 3
- User 4
라이선스가 할당된 그룹(Group 1, Group 3)은 라이선스를 제거한 뒤 삭제 가능42.

그룹에 라이선스가 할당되어 있으면 삭제할 수 없으니, 라이선스를 먼저 제거해야 합니다. 사용자는 라이선스와 관계없이 삭제할 수 있습니다.

Microsoft Entra ID: 클라우드 기반의 ID 및 접근 관리 서비스입니다. (이전 Azure Active Directory)
그룹 (Group): 사용자, 장치 또는 기타 Entra ID 개체의 모음입니다.
라이선스 할당 (License Assigned): 사용자 또는 그룹에 Azure 서비스 사용 권한이 할당된 상태입니다.

정답 (사용자): User 1, User 2, User 3, User 4 (라이선스 할당 여부와 관계없이 모든 사용자를 삭제할 수 있습니다.)

정답 (그룹): Group 2, Group 4 (활성 라이선스가 할당된 그룹은 삭제할 수 없습니다. Group 1과 Group 3에는 라이선스가 할당되어 있으므로 삭제할 수 없습니다.)

문제 153

Microsoft Entra 테넌트가 있습니다. Entra 관리 센터에서 대량 삭제를 사용하여 여러 사용자를 삭제하려고 합니다. 대량 삭제를 위해 만들고 업로드해야 하는 파일에 어떤 사용자 속성을 포함해야 할까요?

보기:

A. 각 사용자의 사용자 계정 이름 및 사용 위치 만 B. 각 사용자의 사용자 계정 이름 만 C. 각 사용자의 표시 이름 만 D. 각 사용자의 표시 이름 및 사용 위치 만 E. 각 사용자의 표시 이름 및 사용자 계정 이름 만

해설:

Microsoft Entra ID: 클라우드 기반의 ID 및 접근 관리 서비스입니다. (이전 Azure Active Directory)
Entra 관리 센터: 웹 브라우저를 통해 Entra ID를 관리할 수 있는 그래픽 사용자 인터페이스입니다.
대량 삭제 (Bulk Delete): 여러 사용자를 한 번에 삭제하는 기능입니다.
사용자 계정 이름 (User Principal Name, UPN): 사용자를 식별하는 고유한 로그인 ID입니다 (예: user@contoso.com).
표시 이름 (Display Name): 사용자에게 친숙한 이름입니다 (예: 홍길동).
사용 위치 (Usage Location): 사용자의 지리적 위치입니다. Azure 서비스의 라이선스 및 지역 제한에 영향을 미칠 수 있습니다.
CSV (Comma Separated Values) 파일: 쉼표로 구분된 텍스트 데이터 형식입니다. 대량 작업에 사용됩니다.

정답: B (Microsoft Entra ID에서 대량 사용자 삭제를 수행할 때 CSV 파일에 필요한 유일한 필수 속성은 각 사용자의 사용자 계정 이름(UPN)입니다.)

문제 154

testRG라는 리소스 그룹을 포함하는 Azure 구독이 있습니다. testRG를 사용하여 Azure 배포를 검증합니다. testRG에는 다음과 같은 리소스가 있습니다.

vm1 (가상 머신, 실행 중, Vault1에 매일 백업하도록 구성됨)
Vault1 (Recovery Services 자격 증명 모음, vm1의 모든 백업 포함)
vnet1 (가상 네트워크, 삭제 잠금 유형의 리소스 잠금 있음)

testRG를 삭제해야 합니다. 가장 먼저 무엇을 해야 할까요?

보기:

A. vm1의 백업 구성 수정 및 vnet1의 리소스 잠금 유형 수정

B. vnet1에서 리소스 잠금 제거 및 Vault1의 모든 데이터 삭제

C. vm1 끄기 및 vnet1에서 리소스 잠금 제거

D. vm1 끄기 및 Vault1의 모든 데이터 삭제

해설:

이 시나리오에서 testRG 리소스 그룹을 삭제하려면 해당 리소스 그룹에 포함된 모든 리소스를 삭제할 수 있어야 합니다. 그러나 리소스가 삭제 잠금, 백업, 또는 기타 제한 사항으로 인해 삭제되지 않는 경우가 있을 수 있습니다. 각 리소스를 삭제할 수 있는 상태로 만드는 것이 중요합니다.

문제의 핵심 요소:

vm1은 매일 백업되도록 설정되어 있고, Vault1이라는 Recovery Services 자격 증명 모음에 백업이 포함되어 있습니다.
vnet1에는 리소스 잠금이 설정되어 있습니다.
testRG 리소스 그룹을 삭제하려면 잠금 해제 및 백업 데이터를 삭제하는 것이 필요합니다.

각 옵션 검토:

A. vm1의 백업 구성 수정 및 vnet1의 리소스 잠금 유형 수정
이 옵션은 vm1의 백업 구성을 수정하고, vnet1의 리소스 잠금 유형을 수정하는 것인데, 이 옵션이 목적을 달성하는 데 도움이 될 수 있습니다. 그러나 vnet1의 리소스 잠금을 해제하고 Vault1의 데이터 삭제도 필요합니다.
B. vnet1에서 리소스 잠금 제거 및 Vault1의 모든 데이터 삭제
이 옵션은 vnet1에서 리소스 잠금을 제거하고, Vault1의 데이터를 삭제하여 백업을 제거하는 것입니다. 이렇게 하면 testRG 리소스 그룹을 삭제할 수 있습니다. Vault1의 데이터 삭제는 중요한 단계입니다.
C. vm1 끄기 및 vnet1에서 리소스 잠금 제거
vm1을 끄는 것만으로는 백업 설정이 유지됩니다. Vault1의 데이터가 삭제되지 않으면 백업과 관련된 리소스를 제거할 수 없습니다. 리소스 잠금만 해제하는 것으로는 충분하지 않습니다.
D. vm1 끄기 및 Vault1의 모든 데이터 삭제
vm1을 끄는 것만으로는 testRG 삭제에 영향을 미치지 않습니다. 하지만 Vault1의 모든 데이터 삭제는 필요합니다.

결론: B. vnet1에서 리소스 잠금 제거 및 Vault1의 모든 데이터 삭제

이 옵션이 testRG를 삭제할 수 있게 해주는 모든 단계를 포함하고 있습니다. Vault1의 데이터 삭제와 vnet1의 리소스 잠금을 제거해야 리소스 그룹을 삭제할 수 있습니다.

리소스 그룹 (Resource Group): 관련된 Azure 리소스들을 논리적으로 묶어 놓은 컨테이너입니다.
가상 머신 (Virtual Machine, VM): 클라우드에서 실행되는 가상의 컴퓨터입니다.
Recovery Services 자격 증명 모음 (Recovery Services Vault): Azure Backup 데이터를 저장하는 곳입니다.
가상 네트워크 (Virtual Network, VNet): Azure에서 생성하는 사설 네트워크입니다.
리소스 잠금 (Resource Lock): Azure 리소스의 실수로 인한 삭제 또는 수정을 방지하는 기능입니다. 삭제 잠금은 리소스 삭제를 금지합니다.
백업 구성 (Backup Configuration): 백업 빈도, 보존 기간 등을 설정하는 것입니다.

정답: B (리소스 그룹을 삭제하려면 해당 그룹 내의 모든 리소스에 삭제를 막는 리소스 잠금이 없어야 합니다. vnet1에 삭제 잠금이 있으므로 먼저 이를 제거해야 합니다. 또한 Recovery Services 자격 증명 모음에 백업 데이터가 있는 경우 삭제할 수 없으므로 Vault1의 모든 백업 데이터를 삭제해야 합니다.)

문제 155

Azure 구독에 다음과 같은 리소스가 있습니다.

vm1 (가상 머신, East US 위치)
storage1 (스토리지 계정, West US 위치)

storage1과 vm1 간의 데이터 전송이 인터넷을 거치지 않도록 해야 합니다. storage1에 대해 무엇을 구성해야 할까요?

보기:

A. 데이터 보호

B. 개인 엔드포인트 (Private Endpoint)

C. 방화벽 및 가상 네트워크 설정에서 공용 네트워크 접근

D. SAS (Shared Access Signature)

해설:

Azure에서 서로 다른 지역에 위치한 가상 머신(vm1)과 스토리지 계정(storage1) 간 데이터 전송 시 인터넷 경유를 방지하려면 개인 엔드포인트(Private Endpoint)를 구성해야 합니다.

핵심 구성 요소

개인 엔드포인트 생성:
- storage1에 대한 개인 엔드포인트를 생성하면 Azure Virtual Network(vm1의 VNet) 내부에 전용 IP가 할당됩니다15.
- 이 엔드포인트는 Azure 백본 네트워크를 통해 트래픽을 라우팅하므로 인터넷을 경유하지 않습니다1.
공용 엔드포인트 접근 차단:
- 스토리지 방화벽 설정에서 공용 네트워크 접근을 "사용 안 함"으로 변경하여 외부 인터넷 접근을 차단합니다35.
- 이렇게 하면 개인 엔드포인트를 통한 연결만 허용됩니다1.
연결 검증:
- vm1에서 storage1의 개인 엔드포인트 IP로 연결 테스트 시 공용 IP 대신 VNet 내부 IP가 사용됩니다5.

다른 옵션 배제 이유

(A) 데이터 보호: 암호화나 중복 저장과 관련된 기능으로 네트워크 경로 제어와 무관합니다.
(C) 방화벽 설정: 공용 접근 차단은 필요하지만, 단독으로는 VNet 간 프라이빗 연결을 보장하지 않습니다3.
(D) SAS: 접근 권한 부여 수단이지만 네트워크 경로 변경과는 관계없습니다.

따라서 정답은 (B) 개인 엔드포인트입니다.

Azure 가상 머신 (Azure Virtual Machine, VM): 클라우드에서 실행되는 가상의 컴퓨터입니다.
Azure 스토리지 계정 (Azure Storage Account): Azure에서 데이터를 저장하는 기본적인 단위입니다.
데이터 전송 (Data Transfer): 데이터를 한 위치에서 다른 위치로 이동시키는 것입니다.
인터넷 (Internet): 전 세계적으로 연결된 공용 네트워크입니다. 인터넷을 통해 데이터를 전송하는 것은 보안 위험을 초래할 수 있습니다.
Microsoft 백본 네트워크 (Microsoft Backbone Network): Azure 데이터 센터 간의 내부 전용 네트워크입니다. 이 네트워크를 통해 데이터를 전송하는 것은 더 안전하고 효율적입니다.
개인 엔드포인트 (Private Endpoint): 가상 네트워크 내의 개인 IP 주소를 사용하여 Azure 서비스에 비공개로 안전하게 연결하는 방법입니다. 인터넷을 통하지 않고 Microsoft 백본 네트워크를 통해 통신합니다.
공용 네트워크 접근 (Public Network Access): 인터넷을 통해 스토리지 계정에 접근할 수 있도록 허용하는 설정입니다.
방화벽 및 가상 네트워크 설정: 특정 네트워크 또는 IP 주소로부터의 접근을 제한하는 설정입니다. 공용 접근을 완전히 막지는 않습니다.
SAS (Shared Access Signature): 스토리지 계정의 리소스에 대한 제한된 시간 및 권한을 가진 보안 토큰을 생성하는 방법입니다. 데이터 접근을 안전하게 제어할 수 있지만, 트래픽 경로를 변경하지는 않습니다.

정답: B (개인 엔드포인트를 storage1에 구성하면 vm1이 속한 가상 네트워크 내의 개인 IP 주소를 통해 storage1에 안전하게 접근할 수 있게 되어, 데이터 전송이 인터넷을 거치지 않고 Microsoft 백본 네트워크를 통해 이루어집니다.)

문제 156

Azure 구독이 있습니다. 다음과 같은 요구 사항을 충족하는 역할 정의를 만들려고 합니다.

사용자는 스토리지 계정의 구성 데이터를 볼 수 있어야 합니다.
사용자는 가상 네트워크에 대한 모든 작업을 수행할 수 있어야 합니다.
솔루션은 최소 권한 원칙을 준수해야 합니다.

아래 언급된 각 요구 사항에 대해 역할 정의에 무엇을 포함해야 할까요?

가상 네트워크에 대한 모든 작업 수행(Perform all action on a virtual network.)

1) Microsoft.Network/virtualNetworks/*

2) Microsoft.Network/virtualNetworks/delete

3) Microsoft.Network/virtualNetworks/write

스토리지 계정의 구성 데이터 보기

1) Microsoft.Storage/StorageAccounts/*

2) Microsoft.Storage/StorageAccounts/read

3) Microsoft.Storage/StorageAccounts/blobServices/containers/blob/read

해설:

Azure에서 최소 권한 원칙을 준수하는 맞춤형 역할을 정의하려면 다음과 같은 권한을 포함해야 합니다.

1. 가상 네트워크에 대한 모든 작업 수행

필요한 권한:
Microsoft.Network/virtualNetworks/*
- 이유:
  - * 와일드카드는 가상 네트워크 리소스에 대한 모든 작업(생성/수정/삭제/읽기)을 허용합니다.
  - 서브넷, NIC 등 다른 네트워크 리소스에 대한 권한은 포함되지 않아 최소 권한 원칙을 충족합니다4.

2. 스토리지 계정의 구성 데이터 보기

필요한 권한:
Microsoft.Storage/storageAccounts/read
- 이유:
  - 스토리지 계정의 속성(이름, 위치, SKU 등) 및 설정을 조회할 수 있지만, 실제 데이터(Blob/File) 접근 권한은 포함되지 않습니다35.

잘못된 옵션 배제 이유

옵션문제점

Microsoft.Network/virtualNetworks/delete + write	부분적인 권한만 부여하여 모든 작업 요구사항을 충족하지 못함
Microsoft.Storage/storageAccounts/*	불필요한 데이터 평면 권한(Blob/File 쓰기)이 포함될 수 있음
blobServices/containers/blob/read	구성 데이터가 아닌 실제 데이터 접근 권한으로 요구사항과 무관

역할 정의 예시 (JSON)

json

{

"Name": "Custom Network-Storage Role",

"Actions": [

"Microsoft.Network/virtualNetworks/*",

"Microsoft.Storage/storageAccounts/read" ],

"AssignableScopes": [

"/subscriptions/{subscription-id}"

]

}

Azure 구독 (Azure Subscription): Azure 서비스를 사용하기 위한 계정입니다.
역할 정의 (Role Definition): Azure 리소스에 대한 특정 권한 집합을 정의하는 것입니다.
최소 권한 원칙 (Principle of Least Privilege): 작업 수행에 필요한 최소한의 권한만 부여해야 한다는 보안 원칙입니다.
가상 네트워크 (Virtual Network): Azure에서 생성하는 사설 네트워크입니다.
스토리지 계정 (Storage Account): Azure에서 데이터를 저장하는 기본적인 단위입니다.
Azure Resource Manager (ARM) 작업: Azure 리소스에 대해 수행할 수 있는 작업입니다. 형식은 Microsoft.<리소스 공급자>/<리소스 종류>/<작업> 입니다 (예: Microsoft.Network/virtualNetworks/read). *는 모든 작업을 의미합니다.

정답:

가상 네트워크에 대한 모든 작업 수행: Microsoft.Network/virtualNetworks/* (가상 네트워크를 읽고, 만들고, 수정하고, 삭제하는 등 모든 작업을 허용하는 권한입니다.)
스토리지 계정의 구성 데이터 보기: Microsoft.Storage/storageAccounts/read (스토리지 계정의 속성 및 구성을 볼 수 있는 권한입니다. Microsoft.Storage/storageAccounts/*/read와 같이 모든 하위 리소스에 대한 읽기 권한을 부여하는 것보다 최소 권한 원칙에 더 부합합니다.)

문제 157

vm1이라는 Azure 가상 머신과 Vault one이라는 Azure Key Vault가 있습니다.

vm1에서 키 암호화 키를 사용하도록 Azure Disk Encryption을 구성하려고 합니다.

디스크 암호화를 위해 Vault one을 준비해야 합니다.

Vault one에서 수행해야 하는 두 가지 작업은 무엇일까요?

보기:

A. 배포를 위해 Azure Virtual Machines 선택

B. 새 키 만들기

C. 새 비밀 만들기

D. 키 회전 정책 구성

E. 볼륨 암호화를 위해 Azure Disk Encryption 선택

해설:

Azure 가상 머신(vm1)에 Azure Disk Encryption을 구성할 때 KEK(Key Encryption Key)를 사용하려면

Key Vault(Vault one)에 다음 두 가지 작업을 수행해야 합니다.

1. 볼륨 암호화를 위해 Azure Disk Encryption 활성화 (E)

설정 방법:
- Key Vault의 고급 액세스 정책에서 "Azure Disk Encryption for volume encryption" 옵션을 활성화합니다.
- 이 설정은 Azure 플랫폼이 VM의 디스크 암호화/복호화 과정에서 키에 접근할 수 있도록 허용합니다.

2. 새 KEK(키 암호화 키) 생성 (B)

요구 사항:
- RSA 타입의 키를 생성해야 하며, 타원 곡선 키는 지원되지 않습니다.
- Azure CLI(az keyvault key create) 또는 포털에서 생성 가능합니다.

작업 배제 이유

옵션	문제점
A. 배포를 위해 Azure Virtual Machines 선택	VM 배포 권한 설정과 무관하며, KEK 사용과 직접 연결되지 않음
C. 새 비밀 만들기	비밀(Secret)은 암호화 키가 아닌 자격 증명 저장에 사용되므로 KEK 구성과 무관
D. 키 회전 정책 구성	선택적 기능으로 필수 작업에 포함되지 않음

구체적인 구현 단계

Key Vault 액세스 정책 설정 (포털 기준):
- Vault one → 액세스 정책 → "Azure Disk Encryption for volume encryption" 체크 → 저장.
KEK 생성 (CLI 예시):
bash

az keyvault key create --name "vm1-KEK" --vault-name "Vault one" --kty RSA --size 4096

정답: (B) 새 키 만들기, (E) 볼륨 암호화를 위해 Azure Disk Encryption 선택

Azure 가상 머신 (Azure Virtual Machine, VM): 클라우드에서 실행되는 가상의 컴퓨터입니다.
Azure Key Vault: 암호화 키, 비밀 (예: 암호), 인증서를 안전하게 저장하고 관리하는 서비스입니다.
Azure Disk Encryption (ADE): Azure VM의 디스크를 암호화하는 서비스입니다.
키 암호화 키 (Key Encryption Key, KEK): 데이터 암호화 키를 암호화하는 데 사용되는 추가 보안 계층입니다. Key Vault에 저장됩니다.
키 회전 정책 (Key Rotation Policy): 키를 자동으로 주기적으로 변경하는 규칙입니다.

정답: B (새 키 만들기) 및 E (볼륨 암호화를 위해 Azure Disk Encryption 선택)

(설명: Azure Disk Encryption에 키 암호화 키를 사용하려면 Key Vault에 해당 키를 생성해야 합니다. 또한 Key Vault가 Azure Disk Encryption에서 사용될 수 있도록 권한을 부여해야 합니다. Azure Portal의 Key Vault 설정에서 "Azure Disk Encryption for volume encryption" 옵션을 활성화하는 것이 이 권한을 부여하는 방법 중 하나입니다. "배포를 위해 Azure Virtual Machines 선택"은 Key Vault가 VM 배포에 사용될 수 있도록 허용하는 옵션이지만, ADE에 필수는 아닙니다. 키 회전 정책은 선택 사항입니다.)

문제 158

storage1이라는 Azure 스토리지 계정이 있습니다.

사용자가 이름별로 Blob만 안전하게 다운로드할 수 있도록 SAS (Shared Access Signature)를 구성해야 합니다.

어떤 두 가지 설정을 구성해야 할까요?

보기: (그림 참조)

허용된 리소스 유형: 서비스, 컨테이너, 개체
허용된 권한: 읽기, 쓰기, 삭제, 목록, 추가, 만들기,Update, Process, Immutable storage, Permanent delete
Bolb versioning permissions : Enables deletion of versions
Allow blob index permission : Read/Write, Filter

해설:

Azure Blob Storage에서 사용자가 이름으로 특정 Blob을 안전하게 다운로드할 수 있도록 SAS를 구성하려면 다음 두 가지 설정이 필요합니다.

1. 허용된 리소스 유형: 개체 (Object)

이유:
개체(Blob) 수준의 접근만 허용하여 사용자가 특정 Blob에만 접근할 수 있도록 제한합니다.
- 컨테이너나 서비스 전체에 대한 권한을 부여하지 않아 보안성을 높입니다.
- 사용자는 Blob의 정확한 이름을 알고 있어야 하며, 컨테이너 내 Blob 목록 조회는 불가능합니다.

2. 허용된 권한: 읽기 (Read)

이유:
Blob 다운로드를 위한 최소한의 권한인 읽기만 부여합니다.
- 쓰기, 삭제 등의 권한을 포함하면 의도치 않은 데이터 변조 또는 삭제 위험이 발생하므로 제외해야 합니다.

잘못된 옵션 배제 이유

옵션	문제점
허용된 리소스 유형: 컨테이너	사용자가 컨테이너 내 모든 Blob을 조회/삭제할 수 있어 보안 취약.
허용된 권한: 목록 (List)	Blob 이름을 이미 알고 있는 경우 불필요하며, 컨테이너 수준 접근 권한이 필요함.
허용된 권한: 쓰기/삭제	데이터 무결성을 훼손할 수 있어 위험.

구체적인 SAS 생성 예시 (Azure Portal 기준)

리소스 유형: 개체 (Object) 선택.
권한: 읽기 (Read) 만 활성화.
만료 시간: 1시간과 같이 짧은 유효 기간 설정.
프로토콜: HTTPS만 허용으로 보안 강화4.

이렇게 구성하면 사용자는 특정 Blob URL을 정확히 아는 경우에만 안전하게 다운로드할 수 있습니다.

Azure 스토리지 계정 (Azure Storage Account): Azure에서 데이터를 저장하는 기본적인 단위입니다.
Blob (Binary Large Object): 비정형 데이터 (텍스트, 이미지, 비디오 등)입니다.
SAS (Shared Access Signature): 스토리지 계정의 리소스에 대한 제한된 시간 및 권한을 가진 보안 토큰을 생성하는 방법입니다.
허용된 리소스 유형 (Allowed Resource Types): SAS 토큰이 접근할 수 있는 리소스의 유형을 지정합니다 (서비스 전체, 특정 컨테이너, 특정 Blob(개체)).
허용된 권한 (Allowed Permissions): SAS 토큰을 사용하여 수행할 수 있는 작업을 지정합니다 (읽기, 쓰기, 삭제 등).

정답:

허용된 리소스 유형: 개체 (이름별로 특정 Blob에만 접근해야 하므로)
허용된 권한: 읽기 (Blob을 다운로드만 할 수 있도록)

문제 159

storage1이라는 Azure 스토리지 계정을 선택해야 합니다. 솔루션은 다음 요구 사항을 충족해야 합니다.

Azure Data Lake Storage 지원
자주 액세스하지 않는 데이터에 대한 비용 최소화
보조 Azure 지역으로 데이터 자동 복제

storage1에 대해 어떤 세 가지 옵션을 구성해야 할까요? (각 정답은 솔루션의 일부를 나타냅니다.)

보기:

A. 표준 HDD

B. 계층적 네임스페이스 활성화

C. Cool 액세스 계층

D. 표준 SSD

E. GRS (지리 중복 스토리지)

F. LRS (로컬 중복 스토리지)

해설:

Azure Data Lake Storage를 지원하며, 비용 최적화 및 지역 복제를 충족하려면 다음 세 가지 구성을 적용해야 합니다.

1. 계층적 네임스페이스 활성화 (B)

이유:
Azure Data Lake Storage는 계층적 네임스페이스가 활성화된 스토리지 계정에서만 지원됩니다4.
- 이 기능은 디렉토리/파일 구조를 통해 빅데이터 분석 워크로드에 최적화된 성능을 제공합니다.
- 표준 범용 v2 또는 프리미엄 블록 Blob 계정에서만 설정 가능합니다4.

2. Cool 액세스 계층 (C)

이유:
자주 액세스하지 않는 데이터의 저장 비용을 최소화합니다2.
- Cool 계층은 Hot 계층 대비 저장 비용이 40~50% 낮습니다 (예: 미국 동부 기준 Hot: $0.018/GB, Cool: $0.01/GB).
- 데이터는 최소 30일 이상 보관되어야 하며, 조기 삭제 시 패널티가 발생합니다.

3. GRS(지리 중복 스토리지) (E)

이유:
보조 Azure 지역으로 데이터 자동 복제를 보장합니다.
- 주 지역의 데이터가 3회 복제된 후, 페어링된 지역(예: East US ↔ West US)에 추가로 3회 복제됩니다.
- 지역 재해 발생 시 99.99999999999999%(16개 9)의 내구성을 제공합니다.
- LRS(F)는 단일 지역 내 복제만 지원하므로 요구사항 불충족.

잘못된 옵션 배제 이유

옵션	문제점
A/D (HDD/SSD)	스토리지 계정 유형(표준/프리미엄)과 무관하며, Data Lake 지원과 직접 연결되지 않음
F (LRS)	단일 지역 내 복제만 가능하여 보조 지역 자동 복제 요구사항 미충족

구성 결과

구성 항목	적용 값
Data Lake 지원	계층적 네임스페이스 활성화 (B)
비용 최소화	Cool 액세스 계층 (C)
지역 복제	GRS (E)

이 조합으로 빅데이터 분석 호환성, 저장 비용 절감, 재해 복구를 동시에 달성할 수 있습니다.

Azure Data Lake Storage: 대규모 데이터 분석 워크로드에 최적화된 확장 가능하고 비용 효율적인 데이터 레이크 솔루션입니다. 계층적 네임스페이스를 지원합니다.
계층적 네임스페이스 (Hierarchical Namespace): 파일 시스템과 유사한 디렉터리 구조를 제공하여 데이터 관리 및 구성을 용이하게 합니다. Data Lake Storage의 핵심 기능입니다.
액세스 계층 (Access Tier): 데이터의 접근 빈도에 따라 비용을 최적화하기 위한 설정입니다. Hot (자주 접근), Cool (가끔 접근), Archive (거의 접근 안 함)가 있습니다.
비용 최소화 (Minimize Cost): 저장 비용을 줄이는 것입니다. Cool 액세스 계층은 Hot 계층보다 저장 비용이 저렴합니다.
데이터 복제 (Data Replication): 데이터의 가용성과 내구성을 높이기 위해 데이터를 여러 위치에 복사하는 것입니다.
보조 Azure 지역 (Secondary Azure Region): 주 지역에 문제가 발생했을 때 데이터를 복구할 수 있도록 데이터를 복제하는 다른 Azure 지역입니다.
GRS (Geo-Redundant Storage): 주 지역의 단일 데이터 센터 내에서 데이터를 3번 복제하고, 주 지역과 수백 마일 떨어진 보조 지역의 단일 데이터 센터 내에서 데이터를 3번 더 복제합니다. 재해 복구에 적합합니다.
LRS (Locally-Redundant Storage): 주 지역의 단일 데이터 센터 내에서 데이터를 3번 복제합니다. 지역 전체의 장애에는 대비할 수 없습니다.
표준 HDD (Standard Hard Disk Drive): 비용 효율적인 일반적인 스토리지 옵션입니다. 성능이 SSD보다 낮습니다.
표준 SSD (Standard Solid State Drive): HDD보다 높은 성능을 제공하며, 중간 수준의 비용을 가집니다.

정답: B (계층적 네임스페이스 활성화), C (Cool 액세스 계층), E (GRS - 지리 중복 스토리지)

(설명: Azure Data Lake Storage를 지원하려면 계층적 네임스페이스를 활성화해야 합니다. 자주 액세스하지 않는 데이터의 비용을 최소화하려면 Cool 액세스 계층을 사용해야 합니다. 데이터를 보조 Azure 지역으로 자동 복제하려면 GRS를 구성해야 합니다.)

문제 160

다음 표와 같은 장치를 포함하는 Azure 구독이 있습니다.

device1: Windows
device2: Linux
device3: Mac OS
device4: Android

어떤 장치에 Azure Storage Explorer를 설치할 수 있을까요?

보기:

A. device1 만

B. device1 및 device2 만

C. device1 및 device3 만

D. device1, device2 및 device3 만

E. device1, device3 및 device4 만

해설:

Azure Storage Explorer는 Windows, macOS, Linux에서 사용할 수 있는 독립 실행형 앱입니다.

Android는 지원되지 않습니다.

따라서 설치 가능한 장치는 다음과 같습니다:

device1: Windows
device2: Linux
device3: Mac OS

정답은
D. device1, device2 및 device3 만 입니다.

Azure Storage Explorer: Azure Storage 데이터를 시각적으로 탐색하고 관리할 수 있는 무료 독립 실행형 앱입니다.
지원되는 플랫폼: Azure Storage Explorer가 설치되어 실행될 수 있는 운영 체제입니다.

정답: D (Azure Storage Explorer는 Windows, Linux 및 Mac OS를 지원합니다. Android는 지원하지 않습니다.)

문제 161

storage1이라는 Azure 스토리지 계정에 container1과 container2라는 두 개의 컨테이너가 있습니다. 두 컨테이너 모두 Blob 버전 관리가 활성화되어 있으며, 중요한 Blob의 Blob 스냅샷을 주기적으로 생성합니다. 다음과 같은 수명 주기 관리 정책을 만듭니다.

(그림 설명: Azure Resource Manager 템플릿 형식의 수명 주기 관리 정책)

{
  "rules": [
    {
      "enabled": true,
      "name": "rule1",
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "version": {
            "tierToCool": {
              "daysAfterCreationGreaterThan": 15
            },
            "tierToArchive": {
              "daysAfterLastTierChangeGreaterThan": 7,
              "daysAfterCreationGreaterThan": 30
            }
          }
        },
        "filters": {
          "blobTypes": [
            "blockBlob"
          ],
          "prefixMatch": [
            "container1"
          ]
        }
      }
    }
  ]
}

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

Blob 스냅샷은 생성 후 15일이 지나면 자동으로 Cool 액세스 계층으로 이동합니다.
container2의 Blob 버전은 30일이 지나면 자동으로 Archive 액세스 계층으로 이동합니다.
rehydrate된 버전은 container1에서 30일이 지나면 자동으로 Archive 액세스 계층으로 이동합니다.

해설:

1. Blob 스냅샷은 생성 후 15일이 지나면 자동으로 Cool 액세스 계층으로 이동합니다.

거짓 (False)
- 정책의 actions 섹션은 version (Blob 버전)에만 적용되며, snapshot (스냅샷)에 대한 규칙이 없습니다.
- 스냅샷은 생성 후 15일이 지나도 Cool 계층으로 이동하지 않습니다.

2. container2의 Blob 버전은 30일이 지나면 자동으로 Archive 액세스 계층으로 이동합니다.

거짓 (False)
- 정책의 filters에서 prefixMatch는 container1만 대상으로 합니다.
- container2는 정책 범위에 포함되지 않아 어떠한 작업도 적용되지 않습니다.

3. Rehydrate된 버전은 container1에서 30일이 지나면 자동으로 Archive 액세스 계층으로 이동합니다.

거짓 (False)
- tierToArchive 조건에 daysAfterCreationGreaterThan: 30과 daysAfterLastTierChangeGreaterThan: 7이 설정되었습니다.
- Rehydrate(온라인 계층 복원) 시 마지막 계층 변경 시간이 갱신되며, 복원 후 7일이 지나고 생성 후 30일이 경과하면 다시 Archive로 이동합니다.
  - "rehydrate된 버전은 container1에서 30일이 지나면 자동으로 Archive 액세스 계층으로 이동합니다."
    → 거짓 (False)
    - 반드시 생성 후 30일이 경과하고, rehydrate(계층 변경) 후 7일이 경과해야 하므로,
    - rehydrate가 30일 이전에 일어났다면, rehydrate 후 7일이 더 필요합니다.
    - 항상 30일 후에 자동 이동되는 것은 아닙니다.

정리

1	Blob 스냅샷 Cool 이동	False
2	container2 버전 Archive 이동	False
3	Rehydrate 버전 Archive 이동	False

Blob 버전 관리 (Blob Versioning): Blob의 이전 버전을 자동으로 유지하여 실수로 인한 삭제 또는 수정을 되돌릴 수 있도록 하는 기능입니다.
Blob 스냅샷 (Blob Snapshot): 특정 시점의 Blob 읽기 전용 복사본입니다.
수명 주기 관리 정책 (Lifecycle Management Policy): Blob 데이터의 보존 기간 및 액세스 패턴에 따라 자동으로 액세스 계층을 변경하거나 삭제하는 규칙을 설정하는 것입니다.
버전 (Version): Blob 버전 관리가 활성화된 경우 Blob의 각 수정 사항이 새로운 버전으로 저장됩니다.
액세스 계층 (Access Tier): 데이터의 접근 빈도에 따라 비용을 최적화하기 위한 설정입니다 (Hot, Cool, Archive).
필터 (Filter): 수명 주기 관리 규칙을 특정 Blob에만 적용하기 위한 조건입니다 (예: 특정 접두사(prefix)를 가진 Blob, 특정 Blob 유형).
rehydrate: Archive 액세스 계층의 Blob을 Hot 또는 Cool 액세스 계층으로 임시로 복원하는 과정입니다. Archive 계층은 데이터를 다시 접근하는 데 시간이 오래 걸립니다.

정답:

Blob 스냅샷은 생성 후 15일이 지나면 자동으로 Cool 액세스 계층으로 이동합니까? 아니요. (정책의 actions 섹션에는 version에 대한 규칙만 정의되어 있고, 스냅샷에 대한 규칙은 없습니다.)
container2의 Blob 버전은 30일이 지나면 자동으로 Archive 액세스 계층으로 이동합니까? 아니요. (정책의 filters 섹션에서 prefixMatch가 "container1"로 설정되어 있으므로, 이 정책은 container1의 Blob에만 적용됩니다.)
rehydrate된 버전은 container1에서 30일이 지나면 자동으로 Archive 액세스 계층으로 이동합니까? 아니요. (rehydrate된 Blob 버전은 원래 생성 날짜를 유지하며, tierToArchive 규칙의 daysAfterCreationGreaterThan: 30 조건에 따라 즉시 Archive 계층으로 다시 이동할 수 있습니다. 또한 daysAfterLastTierChangeGreaterThan: 7 조건도 적용될 수 있습니다.)

문제 162

다음 표와 같은 가상 네트워크를 포함하는 Azure 구독이 있습니다.

vnet1: West US
vnet2: Central Europe

vnet1과 vnet2 간의 모든 트래픽이 Microsoft 백본 네트워크를 통과하도록 해야 합니다. 무엇을 구성해야 할까요?

보기:

A. 개인 엔드포인트 (Private Endpoint)

B. 피어링 (Peering)

C. ExpressRoute

D. 경로 테이블 (Route Table)

해설:

Azure 가상 네트워크(vnet1과 vnet2) 간 트래픽을 Microsoft 백본 네트워크로 전송하려면 **B. 피어링(Peering)**을 구성해야 합니다.

핵심 원리

글로벌 VNet 피어링
- 서로 다른 Azure 지역(West US ↔ Central Europe)에 위치한 가상 네트워크를 연결합니다.
- 트래픽은 공용 인터넷이 아닌 Microsoft의 전용 백본 네트워크를 통해 라우팅됩니다14.
자동화된 라우팅
- 피어링이 설정되면 Azure가 자동으로 두 VNet 간의 라우팅 테이블을 업데이트합니다.
- 별도의 게이트웨이 또는 VPN 구성 없이도 낮은 지연 시간과 높은 대역폭을 보장합니다5.

다른 옵션 배제 이유

A. 개인 엔드포인트	Azure 서비스(스토리지, SQL DB 등)에 대한 프라이빗 연결용이며, VNet 간 통신과 무관
C. ExpressRoute	온-프레미스 네트워크와 Azure 연결용이며, VNet 간 통신에는 과도한 구성
D. 경로 테이블	트래픽 경로를 수동으로 제어하지만 백본 네트워크 사용을 강제하지 않음

구성 단계 (CLI 예시)

bash

# vnet1과 vnet2 간 글로벌 피어링 설정

az network vnet peering create \

--name vnet1-to-vnet2 \

--resource-group RG1 \

--vnet-name vnet1 \

--remote-vnet /subscriptions/{sub-id}/resourceGroups/RG2/providers/Microsoft.Network/virtualNetworks/vnet2 \

--allow-vnet-access

결과:

vnet1과 vnet2의 VM은 개인 IP 주소로 직접 통신하며, 모든 트래픽은 Azure 백본을 경유합니다.

Azure 가상 네트워크 (Azure Virtual Network, VNet): Azure에서 생성하는 사설 네트워크입니다.
Microsoft 백본 네트워크 (Microsoft Backbone Network): Azure 데이터 센터 간의 내부 전용 네트워크입니다.
개인 엔드포인트 (Private Endpoint): 가상 네트워크 내의 개인 IP 주소를 사용하여 Azure 서비스에 비공개로 안전하게 연결하는 방법입니다. 동일한 가상 네트워크 내의 서비스에 대한 비공개 연결에 주로 사용됩니다.
가상 네트워크 피어링 (Virtual Network Peering): 서로 다른 가상 네트워크 간에 사설 IP 주소를 사용하여 연결을 생성하여 마치 하나의 가상 네트워크처럼 통신할 수 있도록 하는 Azure 기능입니다. 지역 간 피어링을 통해 다른 지역의 가상 네트워크도 연결할 수 있으며, 트래픽은 Microsoft 백본 네트워크를 통해 이동합니다.
ExpressRoute: 온-프레미스 네트워크와 Azure 간에 전용 사설 연결을 만드는 서비스입니다.
경로 테이블 (Route Table): 가상 네트워크 내에서 네트워크 트래픽의 경로를 제어하는 데 사용됩니다. 트래픽이 Microsoft 백본 네트워크를 통과하도록 강제하는 직접적인 방법은 아닙니다.

정답: B (가상 네트워크 피어링을 vnet1과 vnet2 사이에 구성하면 두 가상 네트워크 내의 리소스가 개인 IP 주소를 사용하여 서로 통신할 수 있게 되며, 지역 간 피어링의 경우 트래픽은 안전한 Microsoft 백본 네트워크를 통해 이동합니다.)

문제 163

Azure 구독이 있고 다음과 같은 설정으로 새 Azure Container Instance를 만들고 있습니다.

컨테이너 이름: cont1
SKU: Standard
OS 유형: Windows
네트워킹 유형: 공용
메모리 GiB: 2.5
CPU 코어 수: 2

네트워킹 유형에 대해 개인 설정이 사용할 수 없다는 것을 발견했습니다.

cont1이 개인 네트워킹을 사용하도록 구성하려면 어떤 설정을 변경해야 할까요?

보기:

A. 메모리 GiB

B. 네트워킹 유형

C. CPU 코어 수

D. OS 유형

E. SKU

해설:

이 시나리오에서 **Azure Container Instance (ACI)**를 개인 네트워크에 배포하려는 경우, 가장 중요한 제약 조건 중 하나는 OS 유형입니다. 현재 설정된 OS 유형이 Windows인 경우, ACI는 Windows 기반 컨테이너에서 개인 네트워킹을 지원하지 않습니다.

Azure에서는 개인 네트워킹(예: VNet 통합)을 통해 ACI가 가상 네트워크에 배치되도록 할 수 있지만, 이는 리눅스 기반 컨테이너에서만 지원됩니다.

✅ 정답: D. OS 유형

왜 다른 보기들이 아닌가요?

A. 메모리 GiB	컨테이너의 메모리 용량 설정	❌ 무관
B. 네트워킹 유형	이미 "공용"에서 "개인"으로 바꾸려는 시도 중	❌ 선택 불가 이유는 네트워킹 유형 자체 때문이 아님
C. CPU 코어 수	처리 성능 설정	❌ 무관
D. OS 유형	현재 Windows → Linux로 변경해야 개인 네트워크 가능	✅ 영향 있음
E. SKU	ACI에는 SKU 선택이 거의 없으며, 리소스 수준만 다를 뿐 네트워킹에 영향 없음	❌ 무관

🔍 추가 설명

Azure 공식 문서에 따르면:

"You can deploy Linux containers to a virtual network, but Windows containers do not currently support virtual network deployment."
출처: Microsoft Docs - Azure Container Instances networking

Azure Container Instances (ACI): 서버를 관리할 필요 없이 Azure에서 Docker 컨테이너를 실행할 수 있는 서비스입니다.
SKU (Stock Keeping Unit): ACI의 성능 및 기능 계층을 나타냅니다.
OS 유형 (OS Type): 컨테이너가 실행될 운영 체제입니다 (Windows 또는 Linux).
네트워킹 유형 (Networking Type): 컨테이너 인스턴스의 네트워크 연결 방식을 결정합니다.
- 공용 (Public): 컨테이너에 공용 IP 주소를 할당하여 인터넷에서 직접 접근할 수 있도록 합니다.
- 개인 (Private): 컨테이너를 Azure 가상 네트워크에 연결하여 개인 IP 주소를 할당하고 가상 네트워크 내에서만 접근할 수 있도록 합니다.
- 없음 (None): 컨테이너에 IP 주소를 할당하지 않습니다.
가상 네트워크 (Virtual Network): Azure에서 생성하는 사설 네트워크입니다.

정답: B (네트워킹 유형을 '공용'에서 '개인'으로 변경하면 컨테이너 인스턴스를 Azure 가상 네트워크에 연결하고 개인 IP 주소를 할당받아 개인 네트워킹을 사용할 수 있게 됩니다.)

문제 164

West US Azure 지역에 여러 가상 머신이 포함된 Azure 구독이 있습니다. Azure Network Watcher에서 트래픽 분석을 사용하여 가상 네트워크 트래픽을 모니터링해야 합니다. 어떤 두 가지 리소스를 만들어야 할까요?

보기:

A. Log Analytics 작업 영역

B. Azure Monitor 통합 문서

C. 스토리지 계정

D. Microsoft Sentinel 작업 영역

E. Azure Monitor의 데이터 수집 규칙 (DCR)

해설:

트래픽 분석(Traffic Analytics)은 Azure Network Watcher의 기능 중 하나로, 가상 네트워크의 NSG(네트워크 보안 그룹) 흐름 로그를 수집하고 분석하여 트래픽 흐름, 위협 탐지 등을 시각화합니다.
이를 사용하기 위해 필수적으로 설정해야 하는 두 가지 리소스는 다음과 같습니다:

✅ 정답:

A. Log Analytics 작업 영역
C. 스토리지 계정

🔍 이유 및 설명:

1. Log Analytics 작업 영역 (A)

트래픽 분석 데이터를 시각화하고 쿼리하기 위해 로그를 저장할 공간이 필요합니다.
→ 이 작업 영역은 트래픽 분석 결과 데이터를 저장 및 분석하는 중심 플랫폼입니다.

2. 스토리지 계정 (C)

NSG 흐름 로그를 활성화하면 로그는 먼저 스토리지 계정에 저장됩니다.
→ 트래픽 분석은 이 데이터를 기반으로 시각화 및 인사이트를 생성합니다.

📉 왜 다른 보기들은 정답이 아닌가?

보기 설명 트래픽 분석에 필요 여부

A. Log Analytics 작업 영역	분석 쿼리 및 시각화에 필요	✅ 필요
B. Azure Monitor 통합 문서	트래픽 분석 설정과 직접적 관계 없음	❌ 불필요
C. 스토리지 계정	흐름 로그 저장에 필요	✅ 필요
D. Microsoft Sentinel 작업 영역	보안 분석 플랫폼이며, 트래픽 분석에 직접 사용되진 않음	❌ 불필요
E. Azure Monitor의 데이터 수집 규칙 (DCR)	트래픽 분석은 NSG 흐름 로그 기반이라 DCR이 필요하지 않음	❌ 불필요

📚 참고 링크

Azure Network Watcher: Azure 네트워크를 모니터링하고 진단하는 서비스입니다.
트래픽 분석 (Traffic Analytics): Azure 네트워크 트래픽의 흐름에 대한 인사이트를 제공하는 Network Watcher 기능입니다.
가상 네트워크 (Virtual Network): Azure에서 생성하는 사설 네트워크입니다.
Log Analytics 작업 영역 (Log Analytics Workspace): Azure Monitor 로그 데이터를 저장하고 분석하는 중앙 집중식 저장소입니다. 트래픽 분석 데이터가 저장되는 곳입니다.
스토리지 계정 (Storage Account): Azure에서 데이터를 저장하는 기본적인 단위입니다. 트래픽 분석 구성 정보를 저장하는 데 사용됩니다.
Azure Monitor 통합 문서 (Azure Monitor Workbook): 시각적인 보고서 및 대시보드를 만드는 데 사용됩니다. 트래픽 분석 결과를 시각화하는 데 사용할 수 있지만, 트래픽 분석 자체에 필수는 아닙니다.
Microsoft Sentinel 작업 영역: 클라우드 기반의 SIEM (Security Information and Event Management) 및 SOAR (Security Orchestration, Automation and Response) 솔루션입니다. 네트워크 보안 분석에 사용되지만, 기본적인 트래픽 분석에는 필수는 아닙니다.
데이터 수집 규칙 (Data Collection Rule, DCR): Azure Monitor에서 데이터를 수집하는 방식을 정의합니다. 트래픽 분석 데이터 수집을 위해 사용될 수 있지만, Log Analytics 작업 영역과 스토리지 계정 구성이 먼저 필요합니다.

정답: A (Log Analytics 작업 영역) 및 C (스토리지 계정)

(설명: Azure Network Watcher의 트래픽 분석을 사용하려면 네트워크 보안 그룹(NSG) 흐름 로그를 수집하고 처리할 Log Analytics 작업 영역과 트래픽 분석 구성을 저장할 스토리지 계정이 필요합니다.)

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

AZ-104 시험 대비 문제 we-part2 (0)	2025.04.22
AZ-104 시험 대비 문제 we-part1 (0)	2025.04.22
Azure 주요 용어들의 상관 관계 (0)	2025.04.21
AZ104 예제 문제 "Deploy and manage Azure compute resources (20–25%)" 3 (0)	2025.04.21
AZ104 예제 문제 "Deploy and manage Azure compute resources (20–25%)" 2 (0)	2025.04.21