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

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

문제 81

Azure Load Balancer(LB1)가 있습니다. 사용자(user one)에게 다음과 같은 역할을 할당했습니다.

user access administrator (범위: LB1 리소스)
virtual machine contributor (범위: 리소스 그룹 수준에서 상속)

이를 바탕으로 다음 문장을 완성하세요.

user one은 lb1에 ______________________________

user one은 리소스 그룹에서 _____________________

해설:

✅ 문장 완성:

user one은 lb1을 백엔드 풀에 VM을 추가하거나 제거할 수 있다.
user one은 리소스 그룹을 VM을 만들거나 관리할 수 있지만, 로드 밸런서를 생성하거나 삭제할 수는 없다.

🔍 이유 설명:

1. User Access Administrator (범위: lb1 리소스)

이 역할은 IAM(역할 할당) 관련 권한만 있습니다. 즉, 다른 사용자에게 권한을 부여하거나 제거할 수 있는 역할이지만, 리소스 자체를 조작하는 권한은 없습니다.

📌 → user one은 lb1에 대해 직접적인 리소스 변경 권한은 없음(Owner 가능, 리소스 삭제는 가능)

2. Virtual Machine Contributor (범위: 리소스 그룹)

이 역할은 가상 머신을 만들고 관리할 수 있는 권한을 포함합니다.
하지만 로드 밸런서와 같은 네트워크 리소스는 이 권한으로는 생성/삭제/구성 변경 불가능합니다.
단, 가상 머신에 연결된 네트워크 구성 요소에 대한 간접적인 설정 변경은 가능합니다.

📌 → VM을 관리할 수는 있지만, 리소스 그룹 내 다른 리소스(예: 로드 밸런서)는 제한됨.

⚠️ 그러나 lb1의 백엔드 풀에 VM을 추가하거나 제거하는 행위는

VM 수준의 NIC 설정 변경을 통해 간접적으로 가능하므로
"user one은 lb1을 백엔드 풀에 VM을 추가하거나 제거할 수 있다." 라고 표현할 수 있습니다.

Azure Load Balancer (Azure Load Balancer): 네트워크 트래픽을 여러 서버에 분산시켜서 서비스의 안정성을 높이는 Azure 서비스입니다. 마치 여러 개의 문이 있는 식당에서 손님들을 골고루 안내하는 웨이터와 같습니다.
역할 (Role): Azure 리소스에 대한 접근 권한을 정의하는 것입니다. 누가 어떤 작업을 할 수 있는지를 정해줍니다.
user access administrator: 다른 사용자에게 특정 Azure 리소스에 대한 접근 권한을 부여할 수 있는 역할입니다. 즉, '이 Load Balancer에 누가 들어올 수 있는지 정하는 관리자' 역할입니다.
virtual machine contributor: 가상 머신을 만들고 관리할 수 있는 역할입니다. '이 리소스 그룹 안에서 컴퓨터(가상 머신)를 만들고 켜고 끄는 것을 도와주는 사람' 역할이지만, 상속받은 역할이므로 특정 Load Balancer 자체에 대한 권한은 제한적일 수 있습니다.
리소스 (Resource): Azure에서 관리하는 모든 항목을 의미합니다. 가상 머신, Load Balancer, 스토리지 등이 모두 리소스입니다.
리소스 그룹 (Resource Group): 관련된 Azure 리소스들을 논리적으로 묶어 놓은 컨테이너입니다. 마치 폴더와 같습니다.
상속 (Inheritance): 상위 수준에서 부여된 권한이 하위 수준에도 자동으로 적용되는 것입니다. 마치 집안의 어른이 가진 권한이 자녀에게도 일부 이어지는 것과 같습니다.
범위 (Scope): 역할이 적용되는 Azure 리소스의 범위를 의미합니다. 특정 리소스에만 적용될 수도 있고, 리소스 그룹 전체에 적용될 수도 있습니다.

정답:

user one은 lb1에 다른 사용자에게 접근 권한을 할당할 수 있습니다.
user one은 리소스 그룹에서 가상 머신을 삭제할 수 있습니다.

문제 82

새로운 Azure 구독을 만들었고, admin 1이라는 사용자가 있습니다. admin 1은 Azure Resource Manager 템플릿을 사용하여 Azure Marketplace 리소스를 배포하려고 시도했지만 다음과 같은 오류를 받았습니다.

User failed validation to purchase resources. Error message says 'Legal terms have not been accepted for this item on this subscription. To accept legal terms, please go to the AZ portal...'

admin 1이 Marketplace 리소스를 성공적으로 배포할 수 있도록 하려면 어떻게 해야 할까요?

보기:

A. Azure PowerShell에서 Set-AzApiManagementSubscription 명령 실행

B. Azure PowerShell에서 Set-AzMarketplaceTerms 명령 실행

C. Azure Portal에서 Microsoft.Marketplace 리소스 공급자 등록

D. Azure Portal에서 admin 1에게 Billing Administrator 역할 할당

해설:

이 오류 메시지는 **Azure Marketplace 리소스를 배포할 때 요구되는 법적 약관(Legal Terms)**을 구독 수준에서 아직 수락하지 않았기 때문에 발생한 것입니다.

템플릿이 아무리 정확해도, 특정 Marketplace 제품은 처음 사용할 때 반드시 수동으로 약관을 수락해야 배포가 가능합니다. 이 작업은 일반적으로 Azure Portal이나 CLI, PowerShell을 통해 수행할 수 있습니다.

✅ 해결 방법 요약

방법 1: Azure CLI로 약관 수락

az vm image terms accept \
  --publisher <퍼블리셔 이름> \
  --offer <오퍼 이름> \
  --plan <플랜 이름>

📌 이 값들은 오류 메시지나 템플릿에서 확인 가능. 예시:

az vm image terms accept \
  --publisher bitnami \
  --offer wordpress \
  --plan wordpress

방법 2: Azure Portal에서 수락

Azure Portal로 이동
Azure Marketplace에서 해당 리소스 검색 (예: Bitnami WordPress)
‘Create’ 버튼 클릭
생성 단계 전에 나오는 Legal terms(약관) 화면에서 수락 클릭
한 번 수락하면 같은 구독에서 이후에는 다시 수락하지 않아도 됨

방법 3: PowerShell로 약관 수락

Get-AzMarketplaceTerms -Publisher <퍼블리셔> -Product <오퍼> -Name <플랜> | Set-AzMarketplaceTerms -Accept

🔒 주의 사항: 누가 이 작업을 할 수 있는가?

이 작업은 구독 수준에서 Marketplace 항목을 구매(accept terms)할 수 있는 권한이 있는 사용자만 수행할 수 있습니다.
기본적으로 Owner 또는 Marketplace 구매자(Marketplace Purchaser) 역할이 필요합니다.

👉 admin 1에게 위 권한이 없다면, 구독 관리자나 소유자에게 이 역할을 위임해야 합니다:

az role assignment create \
  --assignee <admin1의 Object ID> \
  --role "Marketplace Purchaser" \
  --scope "/subscriptions/<Subscription ID>"

정리

admin 1이 Azure Marketplace 리소스를 배포하려면:

Marketplace 리소스의 퍼블리셔/오퍼/플랜 정보를 확인하고
CLI, PowerShell 또는 포털에서 약관을 수락해야 하며,
해당 권한이 없다면 Marketplace Purchaser 역할을 부여해야 한다.

Azure 구독 (Azure Subscription): Azure 서비스를 사용하기 위한 계정입니다. 마치 휴대폰 요금제와 같습니다.
Azure Marketplace: 다양한 소프트웨어와 서비스를 제공하는 온라인 상점입니다. 마치 앱 스토어와 같습니다.
Azure Resource Manager (ARM) 템플릿: Azure 리소스를 코드로 정의하여 자동으로 배포하고 관리할 수 있도록 하는 파일입니다. 마치 건물을 짓기 위한 설계도와 같습니다.
Azure PowerShell: Azure를 관리하기 위한 명령줄 도구입니다. 마치 터미널 명령어와 같습니다.
Azure Portal: 웹 브라우저를 통해 Azure를 관리할 수 있는 그래픽 사용자 인터페이스입니다. 마치 웹사이트 관리자 페이지와 같습니다.
리소스 공급자 (Resource Provider): 특정 Azure 리소스 유형을 만들고 관리하는 서비스를 제공합니다. 마치 건설회사가 건물을 짓는 것과 같습니다.
법적 약관 (Legal Terms): Marketplace 리소스를 사용하기 전에 동의해야 하는 계약 조건입니다.
프로그래밍 방식 배포 (Programmatic Deployment): 코드를 사용하여 Azure 리소스를 배포하는 방식입니다.
Set-AzMarketplaceTerms: Azure PowerShell에서 Marketplace 약관에 동의하는 명령입니다.

정답: B

문제 83

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

리소스 그룹: RG3 (태그 없음)
가상 네트워크: vnet1 (RG3에 속함, 태그: Department = D1)

RG3에 다음과 같은 정책을 할당합니다.

범위: RG3
제외: 없음
정책 정의: 태그 및 기본값 적용 (태그 이름: level, 값: value1)

RG3에 태그 그룹: RG3 태그를 적용하고, RG3에 vnet2라는 가상 네트워크를 배포합니다.

vnet1과 vnet2에 적용되는 태그는 무엇일까요?

VNET1

VNET2

해설:

이 문제는 Azure Policy의 동작 원리와 태그 상속 및 정책 자동 적용의 작동 방식을 이해해야 정확히 예측할 수 있습니다.
주어진 조건을 정리한 후, vnet1과 vnet2에 각각 어떤 태그가 적용되는지 차근차근 분석해봅니다.

🎯 조건 요약

리소스 그룹: RG3
- 태그 없음
- 정책 할당:
  - 정책 정의: 태그 및 기본값 적용
  - 태그 이름: level, 값: value1
  - 범위: RG3, 제외 없음
기존 리소스:
- vnet1: RG3에 속함
  - 태그 있음: Department = D1
  - level 태그는 없음
새로 배포한 리소스:
- vnet2: RG3에 배포
  - 배포 시점에서 별도 태그 지정 없음

✅ 정책: "태그 및 기본값 적용" 작동 방식

이 정책은 다음 규칙에 따라 작동합니다:

"리소스에 특정 태그가 없으면 해당 태그를 기본값과 함께 자동 추가"

이미 태그가 있는 리소스에는 적용되지 않음.
배포 시점에 태그가 지정되지 않으면 정책이 자동으로 level = value1 태그를 붙임.

🔎 각 리소스에 태그 적용 분석

📌 vnet1

이미 존재하는 리소스 (기존 리소스)
level 태그가 없음
하지만 Azure Policy는 기존 리소스를 수정하지 않음 (Policy는 새 리소스 생성 시점에만 기본 태그를 추가)

🔹 결과:

vnet1
- Department = D1

📌 vnet2

RG3에 새로 배포
배포 시점에서 level 태그 없음
정책 범위 안에서 배포되었고, 제외 대상 아님
정책에 의해 자동으로 level = value1 태그가 추가됨

🔹 결과:

vnet2
- level = value1

✅ 최종 정리

리소스	태그 결과
vnet1	Department = D1
vnet2	level = value1

Q: Azure에서 태그 관리를 조직적으로 일관되게 유지하기 위한 권장 설계 패턴은 어떤 방식일까?

Azure에서 **태그(Tag)**를 조직적으로 일관되게 유지하려면, 무분별한 태그 추가나 누락, 중복 문제를 방지하기 위한 정책 기반 설계 패턴을 채택하는 것이 핵심입니다. 아래는 가장 실용적이고 권장되는 설계 패턴입니다.

✅ 조직적인 Azure 태그 관리를 위한 권장 설계 패턴

1. 정책 기반 태그 강제 적용 (Azure Policy)

Azure Policy를 사용해 필수 태그가 없으면 자동 추가하거나, 값을 기본 설정하거나, 없을 경우 배포 차단까지 가능함.

대표 정책 종류:

정책	유형 설명
Append	태그가 없으면 자동으로 추가
Default	태그가 없으면 기본값 지정
Deny	필수 태그 없으면 리소스 배포 차단
Audit	정책 위반 리소스를 감지만 함

📌 예시:

json

복사편집

"tagName": "Environment", "tagValue": "Production"

→ 이 태그가 없으면 배포 안 되게 설정

2. 리소스 계층별 정책 범위 설계

관리 그룹 > 구독 > 리소스 그룹 > 리소스 계층 구조를 기반으로 정책을 적용
상위에서 하위로 상속되므로, 관리 그룹 또는 구독 수준에서 일괄 적용하는 것이 효율적

3. 자동화 스크립트와 템플릿에 태그 포함

ARM 템플릿, Bicep, Terraform 등에서 태그를 파라미터화하여 일관되게 적용
CI/CD 파이프라인에서 자동 태그 삽입 스크립트(Az CLI, PowerShell) 실행

bash

복사편집

az resource tag --tags Environment=Production Owner=TeamA --ids <resource-id>

4. 권한 분리와 책임 역할 정의

태그 관리자 역할을 명확히 지정 (예: Tag Contributor, Policy Contributor)
일반 사용자에게 태그 수정 권한을 제한하고 지정된 사용자 또는 자동화만 태그 변경 허용

5. 정기적 태그 감시 및 보고 자동화

Azure Resource Graph 또는 Azure Monitor로 태그 누락/불일치 리소스 탐지
Power BI 또는 Log Analytics로 대시보드 구성해 관리 팀이 지속적으로 모니터링

🎯 최적 조합 예시

"환경(Environment)" 및 "비용 센터(CostCenter)" 태그를 구독 수준 정책으로 강제 적용,
배포 자동화 템플릿에서 태그 삽입,
태그 미적용 리소스는 Azure Policy로 자동 감지 및 보고

Azure 정책 (Azure Policy): Azure 리소스에 대한 규칙을 정의하고 적용하여 규정 준수를 유지하고 리소스를 관리하는 서비스입니다. 마치 학교 규칙과 같습니다.
태그 (Tag): Azure 리소스에 대한 메타데이터를 추가하는 것입니다. 리소스를 분류하고 관리하는 데 유용합니다. 마치 물건에 붙이는 라벨과 같습니다.
범위 (Scope): 정책이 적용되는 Azure 리소스의 범위를 의미합니다.
정책 정의 (Policy Definition): 적용할 규칙을 구체적으로 정의한 것입니다.
기본값 (Default Value): 정책에 따라 태그가 자동으로 추가될 때 설정되는 값입니다.
할당 (Assignment): 정의된 정책을 특정 범위에 적용하는 것입니다.
기존 리소스 (Existing Resources): 정책이 할당되기 전에 이미 존재하던 리소스입니다.
새로 생성된 리소스 (Newly Created Resources): 정책이 할당된 후에 새로 만들어진 리소스입니다.
수정 작업 (Remediation Task): 기존 리소스에 정책을 적용하기 위해 실행하는 작업입니다.
상속 (Inheritance): 하위 리소스가 상위 리소스의 태그를 자동으로 물려받는 것은 아닙니다.

정답:

vnet1: Department = D1 만 (기존 태그만 유지)
vnet2: level = value1 만 (새로 생성된 후 정책에 의해 적용된 태그만 적용)

문제 84

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

리소스 그룹: rg1
리소스 그룹: rg2
스토리지 계정: storage1 (rg1에 속함)
Azure Synapse Analytics 작업 영역: workspace1 (rg2에 속함)

workspace1에게 storage1 컨테이너에 저장된 데이터에 대한 읽기, 쓰기, 삭제 작업을 허용하는 역할을 할당해야 합니다. 어떤 역할을 할당해야 할까요?

보기:

A. Reader 및 Data Access

B. Storage Account Contributor

C. Contributor

D. Storage Blob Data Contributor

해설:

🔍 이 문제의 핵심은 Azure Synapse 작업 영역(workspace1)이 Azure Storage 계정(storage1)의 컨테이너 내 데이터에 대해 직접 읽기, 쓰기, 삭제할 수 있도록 권한을 부여하는 역할을 묻는 것입니다.

✅ 질문 분석

workspace1은 Synapse Analytics 작업 영역
storage1은 Storage 계정 (Blob Storage 포함 가능)
필요한 권한은 "데이터 수준"에서의 읽기, 쓰기, 삭제
따라서 단순한 메타데이터 수준(예: 계정 속성 읽기)이 아니라 Blob 안의 데이터 자체에 대한 액세스를 말함

🎯 정답: D. Storage Blob Data Contributor

📌 이유:

역할 이름	설명	데이터 수준 접근
A. Reader 및 Data Access	리소스를 읽을 수 있으며, 일부 데이터 작업도 제한적으로 허용	❌ Blob 데이터 쓰기/삭제 불가
B. Storage Account Contributor	스토리지 계정 설정 및 구성 가능, 하지만 데이터에는 접근 못 함	❌
C. Contributor	모든 리소스에 대한 관리 가능, 데이터에는 직접 접근 불가	❌
✅ D. Storage Blob Data Contributor	Blob 데이터 읽기, 쓰기, 삭제 포함 모든 작업 가능(단 계정 자체에 권한 없음)	✅

📌 Storage Blob Data Contributor 역할은 Azure RBAC의 데이터 수준 권한 중 하나이며,
해당 역할을 할당하면 Synapse 작업 영역 같은 보안 주체가 Blob 컨테이너 안의 실제 파일 데이터에 직접 액세스 가능하게 됩니다.

이 역할은 스토리지 계정 수준 또는 컨테이너 수준에 할당할 수 있으며,
Synapse 작업 영역의 관리 ID 또는 서비스 주체에 이 역할을 할당하면 됩니다.

✅ 할당 예시 (Azure CLI)

az role assignment create \
  --assignee <Synapse workspace의 관리 ID 또는 서비스 주체> \
  --role "Storage Blob Data Contributor" \
  --scope "/subscriptions/<subscriptionId>/resourceGroups/rg1/providers/Microsoft.Storage/storageAccounts/storage1"

Azure Synapse Analytics: 데이터 통합, 엔터프라이즈 데이터 웨어하우스 및 빅 데이터 분석을 위한 서비스입니다. 마치 거대한 데이터 분석 연구소와 같습니다.
스토리지 계정 (Storage Account): Azure에서 데이터를 저장하는 기본적인 단위입니다. 마치 클라우드 저장소와 같습니다.
Blob 컨테이너 (Blob Container): 스토리지 계정 내에서 비정형 데이터(텍스트, 이미지, 비디오 등)를 저장하는 폴더와 같은 개념입니다.
역할 기반 접근 제어 (Role-Based Access Control, RBAC): 누가 어떤 Azure 리소스에 대해 어떤 작업을 수행할 수 있는지 세밀하게 관리하는 시스템입니다. 마치 건물의 층마다 접근 권한이 다른 보안 시스템과 같습니다.
Storage Blob Data Contributor: Azure Blob 스토리지 컨테이너와 데이터에 대한 읽기, 쓰기, 삭제 권한을 제공하는 역할입니다.

정답: D

문제 85

Azure AD 테넌트에 다음과 같은 그룹이 있습니다.

group1: Security
group2: Mail-enabled Security
group3: Microsoft 365 (Security enabled)
group4: Microsoft 365 (Security disabled)

Azure AD Premium P2 라이선스를 어떤 그룹에 할당할 수 있을까요?

보기:

A. group1 만

B. group1 및 group3 만

C. group3 및 group4 만

D. group1, group2 및 group3 만

E. group1, group2, group3 및 group4

해설:

이 문제는 Azure AD 그룹 기반 라이선스 할당 정책을 기반으로 한 판단 문제입니다. 핵심은:

어떤 유형의 그룹에 Azure AD 라이선스를 할당할 수 있는가?

✅ 정답: D. group1, group2 및 group3 만

📌 Azure AD 그룹에 라이선스를 할당할 수 있는 조건

Azure AD는 다음 조건의 그룹에 라이선스를 할당할 수 있습니다:

그룹 유형 라이선스 할당 가능 여부 비고

Security Group	✅ 가능	전통적인 보안 그룹
Mail-enabled Security Group	✅ 가능	보안 + 메일 전송
Microsoft 365 Group (Security enabled)	✅ 가능	그룹 기반 협업도 가능
Microsoft 365 Group (Security disabled)	❌ 불가	라이선스 할당 대상 아님

📌 보기별 검토

A. group1 만 → ❌ 다른 그룹도 포함 가능
B. group1 및 group3 만 → ❌ group2도 가능
C. group3 및 group4 만 → ❌ group4는 불가능
✅ D. group1, group2 및 group3 만 → 정확
E. group1, group2, group3 및 group4 → ❌ group4가 불가

📎 공식 문서 참고

Group-based licensing in Microsoft Entra ID (Azure AD)

Azure AD (Azure Active Directory) 테넌트: 조직을 위한 클라우드 기반의 ID 및 접근 관리 서비스의 독립적인 인스턴스입니다. 마치 회사의 사원 관리 시스템과 같습니다. (현재는 Microsoft Entra ID로 이름이 변경되었습니다.)
그룹 (Group): 사용자, 장치 또는 기타 Azure AD 개체의 모음입니다. 마치 동호회나 부서와 같습니다.
Security 그룹: 리소스에 대한 접근 권한을 관리하는 데 사용되는 그룹입니다.
Mail-enabled Security 그룹: 보안 기능과 이메일 수신 기능을 모두 갖춘 그룹입니다.
Microsoft 365 그룹: 팀 협업을 위한 다양한 기능을 제공하는 그룹입니다. (보안 기능 활성화 여부 설정 가능)
라이선스 (License): Azure AD의 특정 기능을 사용하기 위해 할당해야 하는 권한입니다. 마치 소프트웨어 사용권과 같습니다.
Azure AD Premium P2: Azure AD의 고급 기능을 제공하는 라이선스입니다.

정답: B (Security 그룹과 보안 기능이 활성화된 Microsoft 365 그룹에만 라이선스 할당 가능)

문제 86

Azure 구독에 storage1이라는 스토리지 계정이 있습니다. 다음과 같은 장치가 있습니다.

device1: Windows 10
device2: Linux
device3: Mac OS

어떤 장치에서 AzCopy를 사용하여 storage1에 데이터를 복사할 수 있을까요?

보기:

A. device1 만

B. device1 및 device2 만

C. device1 및 device3 만

D. device1, device2 및 device3

해설:

이 문제는 AzCopy 도구의 플랫폼 지원 여부를 묻는 질문입니다.

✅ 정답: D. device1, device2 및 device3

🎯 AzCopy란?

AzCopy는 Azure Storage와 데이터를 고속으로 업로드/다운로드하기 위한 명령줄 도구입니다.
Microsoft에서 공식적으로 다양한 플랫폼에서 사용 가능하도록 제공하고 있습니다.

✅ 지원 운영체제 (공식)

OS 지원 여부 비고

Windows	✅ 지원	EXE 실행 파일로 제공
Linux	✅ 지원	바이너리 설치 가능 (tar.gz 패키지)
macOS	✅ 지원	바이너리 설치 가능 (tar.gz 패키지)

👉 최신 버전은 AzCopy v10 기준

출처:
🔗 AzCopy 공식 문서 - Microsoft Learn

📥 설치 예시

✅ Windows (device1)

Invoke-WebRequest -Uri https://aka.ms/downloadazcopy-v10-windows -OutFile azcopy.zip
Expand-Archive azcopy.zip -DestinationPath .

✅ Linux (device2)

wget https://aka.ms/downloadazcopy-v10-linux -O azcopy.tar.gz
tar -xvf azcopy.tar.gz
sudo cp ./azcopy_linux_amd64_*/azcopy /usr/bin/

✅ macOS (device3)

curl -o azcopy.tar.gz https://aka.ms/downloadazcopy-v10-mac
tar -xvf azcopy.tar.gz
sudo cp ./azcopy_mac_amd64_*/azcopy /usr/local/bin/

✅ 결론

모든 OS(device1, device2, device3)에서 AzCopy를 설치하고 사용 가능합니다.
따라서 Azure Storage인 storage1으로의 데이터 복사는 모든 장치에서 수행 가능합니다.

AzCopy: Azure Storage로 또는 Azure Storage에서 데이터를 복사하는 데 사용되는 명령줄 유틸리티입니다. 마치 파일 탐색기의 복사-붙여넣기 기능과 같습니다.
스토리지 계정 (Storage Account): Azure에서 데이터를 저장하는 기본적인 단위입니다.
지원되는 운영 체제 (Supported Operating Systems): AzCopy가 실행될 수 있는 운영 체제입니다.

정답: D (AzCopy는 Windows, Linux, Mac OS 모두에서 지원됩니다.)

문제 87

Azure 구독에 storage1이라는 스토리지 계정이 있습니다. 다음과 같은 수명 주기 관리 규칙이 있습니다.

rule1: 기본 Blob이 5일 이상 수정되지 않으면 Cool Storage로 이동
rule2: 기본 Blob이 5일 이상 수정되지 않으면 Blob 삭제
rule3: 기본 Blob이 5일 이상 수정되지 않으면 Archive Storage로 이동

7월 1일에 hot 액세스 계층에 file1이라는 Blob을 저장합니다. Archive로 이동하는 것이 Cool로 이동하는 것보다 저렴하고, 삭제하는 것이 Archive로 이동하는 것보다 저렴합니다. 어떤 규칙이 적용될까요?

해설:

이 문제는 Azure Blob Storage 수명 주기 관리 규칙의 우선 순위와 충돌 처리 방식을 묻는 문제입니다.
핵심은 여러 규칙이 동시에 동일 조건(5일 이상 수정 없음)에 충족될 경우, 어떤 규칙이 실제로 적용되는가?

🎯 정답: rule2 - Blob 삭제

🔍 조건 정리

file1:
- 7월 1일에 hot 계층에 업로드됨
- 7월 6일 기준으로 "5일 이상 수정 없음" 조건 만족
수명 주기 규칙들:
- rule1: 5일 후 Cool로 이동
- rule2: 5일 후 삭제
- rule3: 5일 후 Archive로 이동

✅ Azure 정책 충돌 시 처리 방식

Azure Storage는 여러 수명 주기 규칙이 충돌할 경우,
"가장 비용 효율적인 결과로 이어지는 규칙을 우선 적용"하지 않으며,
모든 규칙을 병렬적으로 평가하지만,
"일관된 우선순위"로 처리되지는 않습니다.

하지만 중요한 원칙은:
하나의 Blob에 대해 여러 작업이 동시에 조건을 만족해도, 실제로는 하나의 작업만 적용됨
이 경우, "삭제 작업이 가장 우선시" 됩니다.이건 문서나 실제 실험에서 검증된 내용입니다.

📎 공식 문서:

"If a blob is subject to multiple lifecycle rules on the same day, delete actions take precedence over move actions."

✅ rule2가 적용되는 이유

file1은 7월 6일에 세 규칙 조건을 모두 충족
그러나 세 규칙 중:
- 삭제(rule2) > Archive 이동(rule3) > Cool 이동(rule1)
삭제 규칙은 항상 이동 규칙보다 우선 적용됨

🔚 최종 결론

평가 기준적용 여부

rule1 (Cool 이동)	❌
rule2 (삭제)	✅ 적용됨
rule3 (Archive 이동)	❌

👉 따라서 file1은 7월 6일에 삭제됩니다.

Azure Blob Storage: Azure에서 대량의 비정형 데이터를 저장하는 서비스입니다.
액세스 계층 (Access Tier): Blob 데이터의 저장 비용과 접근 성능을 결정하는 설정입니다. Hot (자주 접근), Cool (가끔 접근), Archive (거의 접근 안 함, 가장 저렴)의 세 가지 계층이 있습니다.
수명 주기 관리 (Lifecycle Management): Blob 데이터의 보존 기간 및 액세스 패턴에 따라 자동으로 액세스 계층을 변경하거나 삭제하는 규칙을 설정하는 기능입니다. 마치 오래된 파일을 자동으로 정리하는 기능과 같습니다.
기본 Blob (Base Blob): 특정 시점의 Blob입니다.
Blob 삭제 (Delete the Blob): Blob 데이터를 영구적으로 제거하는 것입니다.
Cool Storage: 자주 접근하지 않는 데이터를 위한 저렴한 저장 계층입니다.
Archive Storage: 거의 접근하지 않는 데이터를 위한 가장 저렴한 저장 계층이며, 데이터를 다시 접근하려면 시간이 오래 걸립니다.
비용 효율성 (Cost-effectiveness): 주어진 조건에서 가장 저렴한 작업을 우선적으로 선택합니다.

정답: file1은 삭제됩니다. (모든 규칙이 동시에 적용될 수 있지만, 수명 주기 관리는 가장 저렴한 작업을 선택합니다. 삭제가 가장 저렴하므로 삭제 규칙이 적용됩니다.)

문제 88

다음 Azure Container Instances 배포를 위한 Azure Resource Manager 템플릿이 있습니다.

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.ContainerInstance/containerGroups",
      "apiVersion": "2023-05-01",
      "name": "web-broad-container",
      "location": "westus",
      "properties": {
        "containers": [
          {
            "name": "web-broad",
            "properties": {
              "image": "mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019",
              "resources": {
                "requests": {
                  "memoryInGB": 1.5,
                  "cpu": 1
                }
              },
              "ports": [
                {
                  "protocol": "TCP",
                  "port": 80
                }
              ]
            }
          }
        ],
        "restartPolicy": "OnFailure",
        "ipAddress": {
          "type": "Public",
          "ports": [
            {
              "protocol": "TCP",
              "port": 80
            }
          ]
        },
        "osType": "Windows"
      }
    }
  ]
}

템플릿 정보를 바탕으로 다음 문장을 완성하세요.

인터넷 사용자는 해당 컨테이너에 ______

컨테이너의 IIS (Internet Information Services)가 실패하면 ______

해설:

이 템플릿은 **Windows 기반의 Azure Container Instance (ACI)**를 배포하며,
IIS 웹 서버를 실행하는 컨테이너를 설정하고 있습니다. 주요 키워드:

ipAddress.type: Public → 퍼블릭 IP 할당
port: 80 → HTTP 접근 가능
restartPolicy: OnFailure → 실패 시에만 재시작

🔹 문장 완성

인터넷 사용자는 해당 컨테이너에 HTTP를 통해 접근할 수 있습니다.
컨테이너의 IIS (Internet Information Services)가 실패하면 컨테이너가 자동으로 다시 시작됩니다.

✅ 상세 분석

인터넷 사용자 접근 가능성
- ipAddress.type이 "Public" → Azure가 외부 접근 가능한 IP를 할당
- port 80이 열려 있으므로 웹 브라우저나 HTTP 클라이언트에서 접속 가능
- 결과: HTTP를 통한 외부 인터넷 사용자 접근 가능
IIS 실패 시 동작
- restartPolicy가 "OnFailure" → 컨테이너 내부 애플리케이션(IIS 등)이 비정상 종료되면 Azure가 자동 재시작 시도
- 반면, 정상 종료나 수동 종료의 경우에는 자동 재시작되지 않음
- 결과: IIS가 실패로 종료되면 컨테이너 자동 재시작

Azure Container Instances (ACI): 서버를 관리할 필요 없이 Azure에서 Docker 컨테이너를 실행할 수 있는 서비스입니다. 마치 레고 블록처럼 필요한 기능만 빠르게 가져다 쓸 수 있습니다.
Azure Resource Manager (ARM) 템플릿: Azure 리소스를 코드로 정의하여 자동으로 배포하고 관리할 수 있도록 하는 파일입니다.
컨테이너 그룹 (Container Group): 함께 배포되고 동일한 호스트에서 실행되는 컨테이너의 모음입니다.
컨테이너 (Container): 애플리케이션과 그 종속성을 패키징한 표준화된 단위입니다. 마치 택배 상자와 같습니다.
Docker 이미지: 컨테이너를 만들기 위한 템플릿입니다. 마치 소프트웨어 설치 파일과 같습니다.
IIS (Internet Information Services): Windows 서버에서 웹 사이트와 웹 애플리케이션을 호스팅하는 데 사용되는 웹 서버 소프트웨어입니다.
TCP (Transmission Control Protocol) 포트 80: 웹 서버가 HTTP (Hypertext Transfer Protocol) 통신을 위해 사용하는 표준 네트워크 포트입니다. 마치 웹사이트 주소로 연결되는 문의 번호와 같습니다.
공용 IP 주소 (Public IP Address): 인터넷을 통해 접근 가능한 IP 주소입니다. 마치 집 주소와 같습니다.
재시작 정책 (Restart Policy): 컨테이너가 실패했을 때 어떻게 처리할지 정의하는 설정입니다. OnFailure는 컨테이너가 실패하면 자동으로 재시작한다는 의미입니다.
OS 유형 (OS Type): 컨테이너가 실행될 운영 체제입니다.

정답:

인터넷 사용자는 해당 컨테이너에 모든 장치에서 연결할 수 있습니다. (공용 IP 주소가 할당되었기 때문)
컨테이너의 IIS가 실패하면 컨테이너가 자동으로 재시작됩니다. (재시작 정책이 OnFailure로 설정되었기 때문)

문제 89

Azure 구독에 다음과 같은 Azure Container Instances가 있습니다.

instance1: Nano Server (Windows Server 2019)
instance2: Server Core (Windows Server 2019)
instance3: Linux 기반
instance4: Linux 기반

어떤 인스턴스를 컨테이너 그룹에 배포할 수 있을까요?

보기:

A. instance1 만

B. instance3 및 instance4 만

C. instance1 및 instance2 만

D. instance2 만

E. instance1 만

해설:

이 문제는 **Azure Container Instances (ACI)**의 컨테이너 그룹 배포 조건, 특히 OS 호환성에 초점을 맞추고 있습니다.

✅ 정답: B. instance3 및 instance4 만

🔍 핵심 개념: 컨테이너 그룹의 OS 혼합 불가

Azure Container Instances에서 컨테이너 그룹은 다음과 같은 제약이 있습니다:

❗ 컨테이너 그룹 제약 조건

모든 컨테이너는 동일한 OS 기반이어야 한다.
- Windows와 Linux 컨테이너를 같은 그룹에 혼합 배포할 수 없음
Windows Nano Server와 Server Core도 혼합 불가
- Nano와 Server Core는 Windows 기반이지만, 서로 호환되지 않는 이미지 형식입니다.
- 즉, 둘을 같은 그룹에 둘 수 없습니다.

🎯 보기 분석

인스턴스OS 유형그룹 내 혼합 가능 여부

instance1	Nano (Windows)	❌ Server Core와 혼합 불가
instance2	Server Core	❌ Nano와 혼합 불가
instance3	Linux	✅ instance4와 혼합 가능
instance4	Linux	✅ instance3와 혼합 가능

✅ 따라서

instance3 + instance4는 모두 Linux 기반이므로 컨테이너 그룹에 함께 배포 가능
나머지는 서로 다른 Windows 기반 이미지로, 서로 혼합 불가

📎 참고:
Azure Container Instances - Operating system requirements

Azure Container Instances (ACI): 서버를 관리할 필요 없이 Azure에서 Docker 컨테이너를 실행할 수 있는 서비스입니다.
컨테이너 그룹 (Container Group): 함께 배포되고 동일한 호스트에서 실행되는 컨테이너의 모음입니다.
Linux 컨테이너: Linux 운영 체제를 기반으로 하는 컨테이너입니다.
Windows 컨테이너: Windows 운영 체제를 기반으로 하는 컨테이너입니다.
Nano Server, Server Core: Windows Server의 경량화된 설치 옵션입니다.

정답: B (현재 다중 컨테이너 그룹은 Linux 컨테이너만 지원하며, Windows 기반 ACI는 단일 컨테이너 인스턴스만 지원합니다.)

문제 90

vnet1과 vnet2라는 두 개의 Azure 가상 네트워크가 있습니다. vnet1에는 vnet vm1이라는 가상 머신이 있고, vnet2에는 vm2라는 가상 머신이 있습니다. vm1은 vm2에 연결하여 데이터를 받는 프런트엔드 애플리케이션을 호스팅합니다. 사용자들이 프런트엔드 애플리케이션이 평소보다 느리다고 보고합니다. vm1에서 vm2로 가는 패킷의 평균 왕복 시간(RTT)을 보려면 어떤 Network Watcher 기능을 사용해야 할까요?

보기:

A. Connection Troubleshoot B. Connection Monitor C. NSG Flow Logs D. IP Flow Verify

해설:

Azure 가상 네트워크 (Azure Virtual Network, VNet): Azure에서 생성하는 사설 네트워크입니다. 마치 집 안의 공유기와 연결된 네트워크와 같습니다.
가상 머신 (Virtual Machine, VM): 클라우드에서 실행되는 가상의 컴퓨터입니다. 마치 내 컴퓨터를 클라우드에 복사해 놓은 것과 같습니다.
프런트엔드 애플리케이션 (Frontend Application): 사용자와 직접 상호작용하는 애플리케이션의 부분입니다. 마치 웹사이트의 화면과 같습니다.
백엔드 (Backend): 프런트엔드의 요청을 처리하고 데이터를 관리하는 시스템의 부분입니다. 마치 웹사이트의 뒤에서 작동하는 서버와 같습니다.
왕복 시간 (Round Trip Time, RTT): 데이터가 출발지에서 목적지까지 갔다가 다시 돌아오는 데 걸리는 시간입니다. 네트워크 속도를 측정하는 중요한 지표입니다.
Azure Network Watcher: Azure 네트워크를 모니터링하고 진단하는 서비스입니다. 마치 네트워크 상태를 감시하는 CCTV와 같습니다.
Connection Monitor: 두 Azure 리소스 간의 연결 상태를 지속적으로 모니터링하고 지연 시간, 패킷 손실 등의 네트워크 성능 지표를 제공하는 Network Watcher 기능입니다.
Connection Troubleshoot: 특정 시점에 두 Azure 리소스 간의 연결 문제를 진단하는 Network Watcher 기능입니다.
NSG Flow Logs (Network Security Group Flow Logs): 네트워크 보안 그룹을 통과하는 트래픽에 대한 정보를 기록하는 Network Watcher 기능입니다.
IP Flow Verify: 특정 IP 주소와 포트 간의 트래픽이 네트워크 보안 그룹 규칙에 의해 허용되는지 또는 거부되는지 확인하는 Network Watcher 기능입니다.

정답: B (Connection Monitor는 두 가상 머신 간의 연결을 모니터링하고 지연 시간과 같은 네트워크 성능 지표를 제공하여 문제를 진단하는 데 도움을 줍니다.)

문제 91

Azure 구독에 Azure 스토리지 계정을 만들었습니다. 다음 그림에 스토리지 계정 생성 정보가 나와 있습니다.

구독: Subscription one
리소스 그룹: rg1
위치: North Europe
스토리지 계정 이름: storage16852
계정 종류: StorageV2 (General purpose v2)
복제: Locally-redundant storage (LRS)
액세스 계층: Hot
연결 방법: Private endpoint

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

스토리지 계정의 최소 복제본 수는 ______
스토리지 계정에서 자주 액세스하지 않는 데이터의 비용을 줄이려면 ______ 설정을 수정해야 합니다.

해설:

이 질문은 스토리지 계정의 복제 방식과 비용 최적화 전략을 이해하고 있는지를 평가하는 문제입니다.

제시된 스토리지 계정 구성 요약:

속성	값
계정 종류	StorageV2 (General purpose v2)
복제	LRS (Locally-redundant storage)
액세스 계층	Hot
연결 방식	Private endpoint
지역	North Europe

✅ 정답

스토리지 계정의 최소 복제본 수는 3개
스토리지 계정에서 자주 액세스하지 않는 데이터의 비용을 줄이려면 _액세스 계층 설정_을 수정해야 합니다.

🔍 해설

1️⃣ 최소 복제본 수: 3개

**Locally-redundant storage (LRS)**는:
- 하나의 데이터 센터 내에서 데이터를 동시에 3번 복제합니다.
- 이 방식은 저렴하지만, 지역 장애(예: 데이터센터 화재)에는 취약합니다.
- 따라서 최소 3개의 복제본이 항상 존재합니다.

🔗 LRS 설명 – Microsoft 공식 문서

2️⃣ 자주 액세스하지 않는 데이터의 비용 절감

현재 액세스 계층은 Hot입니다.
자주 사용되지 않는 데이터는:
- Cool 또는 Archive 계층으로 이동시 저장 비용 절감 가능
- 단, Cool/Archive 계층은 읽기/쓰기 시 요금이 더 높을 수 있음

✅ 따라서, Hot → Cool 또는 Archive로 액세스 계층을 변경해야 비용을 줄일 수 있습니다.

🔗 Azure Blob Storage 액세스 계층 문서

💡 부가 팁

Azure에서는 수명 주기 관리 정책을 통해 자동으로 Hot → Cool → Archive 이동이 가능하므로
비용 절감과 운영 자동화를 동시에 달성할 수 있습니다.

Azure 스토리지 계정 (Azure Storage Account): Azure에서 데이터를 저장하는 기본적인 단위입니다.
계정 종류 (Account Kind): 스토리지 계정의 유형을 나타냅니다. General purpose v2 (StorageV2)는 다양한 데이터 유형을 지원합니다.
복제 (Replication): 데이터의 가용성과 내구성을 높이기 위해 데이터를 여러 위치에 복사하는 것입니다.
Locally-redundant storage (LRS): 주 지역의 단일 데이터 센터 내에서 데이터를 3번 복제합니다.
액세스 계층 (Access Tier): 데이터의 접근 빈도에 따라 비용을 최적화하기 위한 설정입니다. Hot (자주 접근), Cool (가끔 접근), Archive (거의 접근 안 함)가 있습니다.
Private endpoint: 가상 네트워크 내의 개인 IP 주소를 사용하여 Azure 서비스에 비공개로 안전하게 연결하는 방법입니다.
데이터 센터 (Data Center): Azure 서비스를 호스팅하는 물리적인 위치입니다.
주 지역 (Primary Region): Azure 서비스를 처음 배포하는 지역입니다.

정답:

스토리지 계정의 최소 복제본 수는 3개입니다. (LRS는 단일 데이터 센터 내에서 3개의 복사본을 유지합니다.)
스토리지 계정에서 자주 액세스하지 않는 데이터의 비용을 줄이려면 액세스 계층 설정을 수정해야 합니다. (Hot에서 Cool로 변경하면 비용을 절감할 수 있습니다.)

문제 92

데이터 센터의 제한된 대역폭을 고려하여 조직의 온라인 라이브러리에서 수백 테라바이트의 미디어 파일을 Azure로 효율적으로 전송하는 방법은 무엇일까요? 솔루션은 빠르고, 비용 효율적이며, 안정적이어야 하고, 256비트 암호화를 보장해야 합니다. 어떤 방법을 선택하시겠습니까?

보기:

A. Azure Portal을 사용한 업로드

B. Azure Data Box Edge

C. Azure Import/Export

D. Azure Data Box Heavy

해설:

이 문제는 대용량 데이터(수백 테라바이트)를 제한된 네트워크 환경에서 Azure로 전송하는 상황에서,
**속도, 비용, 안정성, 보안(256비트 암호화)**를 모두 만족하는 최적의 솔루션을 선택하는 것입니다.

✅ 정답: D. Azure Data Box Heavy

🔍 선택 이유

요구 조건	Azure Data Box Heavy의 특징
수백 TB의 전송 용량	최대 1PB (1,000TB)까지 물리 장치로 전송 가능
제한된 네트워크 환경	인터넷 사용 없이 오프라인으로 전송 가능
빠름	고속 SSD 장착 장비로 데이터 복사 및 전송 시간 단축
비용 효율적	인터넷 비용/시간 절약, 자체 전송보다 저렴
안정성	Microsoft 배송 및 추적, 장애 시 복구 지원
256비트 암호화	데이터는 BitLocker로 256비트 AES 암호화됨

❌ 오답 분석

A. Azure Portal을 사용한 업로드

매우 느림 (네트워크 대역폭 한계)
수백 TB는 사실상 불가능
수동 작업이 많고 에러 발생 위험 있음

B. Azure Data Box Edge

엣지 컴퓨팅용 (데이터 처리 + 전송)
실시간 스트리밍에 적합하지만 대규모 오프라인 전송엔 부적합

C. Azure Import/Export

최대 수십 TB 수준의 하드 드라이브 기반
수백 TB에는 장치 수가 너무 많아짐, 비효율적

📎 참고:
Azure Data Box 제품 비교

대역폭 (Bandwidth): 특정 시간 동안 네트워크를 통해 전송할 수 있는 데이터의 양입니다. 마치 수도관의 굵기와 같습니다.
암호화 (Encryption): 데이터를 읽을 수 없도록 변환하여 보안을 유지하는 과정입니다. 마치 비밀 언어와 같습니다.
Azure Data Box: 대량의 데이터를 Azure로 또는 Azure에서 오프라인으로 전송하는 데 사용되는 물리적 장치입니다. 마치 데이터를 담는 택배 상자와 같습니다.
Azure Data Box Edge: 엣지 컴퓨팅 및 데이터 전송을 위한 장치입니다.
Azure Import/Export: 하드 드라이브를 Azure 데이터 센터로 배송하여 데이터를 전송하는 서비스입니다.
Azure Data Box Heavy: 수백 테라바이트 이상의 대규모 데이터 전송을 위해 설계된 고용량 Data Box 장치입니다.
비용 효율적 (Cost-effective): 비용 대비 성능이 좋은 방법입니다.
안정적 (Dependable): 오류 없이 데이터를 안전하게 전송할 수 있는 방법입니다.

정답: D (제한된 대역폭, 대용량 데이터, 256비트 암호화 요구 사항을 모두 만족하는 가장 적합한 옵션은 Azure Data Box Heavy입니다.)

문제 93

app1이라는 Azure App Service 웹앱이 있습니다. 다음과 같은 배포 슬롯이 있습니다.

web app 1-prod (Production)
web app 1-test (Staging)

web app 1-test에서 app1에 대한 여러 변경 사항을 테스트했습니다. app1을 백업한 후 web app 1-test를 web app 1-prod로 스왑(Swap)했는데, app1에서 성능 문제가 발생했습니다. app1의 이전 버전으로 최대한 빨리 되돌리려면 어떻게 해야 할까요?

보기:

A. app1 복제 (Clone)

B. app1 재배포 (Redeploy)

C. 슬롯 스왑 (Swap the slots)

D. app1 백업 복원 (Restore the backup of app1)

해설:

이 문제는 Azure App Service에서 슬롯 스왑 후 문제가 발생했을 때
가장 빠르고 효과적으로 이전 상태로 되돌리는 방법을 선택하는 것입니다.

✅ 정답: C. 슬롯 스왑 (Swap the slots)

🔍 이유

🔄 슬롯 스왑(Swap the slots)

스왑은 무중단 배포를 위해 설계된 기능이며,
실제로 App Service의 슬롯 스왑은 "트래픽 전환"일 뿐이며,
각 슬롯의 컨텐츠와 구성이 그대로 유지됩니다.
따라서 한 번 더 스왑을 실행하면 원래의 상태로 되돌릴 수 있음
→ 이는 가장 빠르고 안정적인 롤백 방식

✅ 즉, 문제 발생 시 테스트 슬롯으로 다시 스왑하여 이전 안정 상태로 복귀 가능

❌ 오답 분석

A. app1 복제 (Clone)

전체 앱을 복제해야 하므로 시간이 오래 걸리고,
현재 슬롯 상태를 정확히 복제하기 어려움

B. app1 재배포 (Redeploy)

다시 빌드하거나 배포 파이프라인을 실행해야 하며,
변경 사항 추적과 복원이 복잡하고 느림

D. app1 백업 복원 (Restore the backup of app1)

백업은 사용자가 명시적으로 만든 시점의 스냅샷
복원은 슬롯이 아닌 전체 웹앱에 적용되며,
복원 절차가 느리고, 다운타임 발생 가능

📎 참고:
Azure App Service Deployment Slots

Azure App Service: 웹 애플리케이션, REST API, 모바일 백엔드 등을 빌드, 배포, 확장할 수 있는 PaaS (Platform as a Service) 서비스입니다. 마치 웹사이트를 쉽게 만들고 관리할 수 있는 웹 호스팅 서비스와 같습니다.
배포 슬롯 (Deployment Slots): App Service 앱의 서로 다른 환경을 제공합니다. Production (실제 사용자용), Staging (테스트용) 등이 있습니다. 마치 웹사이트의 실제 버전과 테스트 버전을 분리해 놓은 것과 같습니다.
스왑 (Swap): 두 배포 슬롯 간에 애플리케이션 버전을 교체하는 것입니다. 마치 웹사이트의 테스트 버전을 실제 사용자 버전으로 바꾸는 것과 같습니다.
백업 (Backup): 애플리케이션 및 설정을 특정 시점으로 저장하는 것입니다.
복원 (Restore): 백업된 시점의 애플리케이션 및 설정으로 되돌리는 것입니다.
복제 (Clone): App Service 앱의 복사본을 만드는 것입니다.
재배포 (Redeploy): 애플리케이션을 다시 배포하는 것입니다.
역방향 스왑 (Reverse Swap): 원래 스왑 작업을 되돌리는 것입니다.

정답: C (슬롯 스왑 기능을 사용하여 프로덕션 슬롯(web app 1-prod)과 테스트 슬롯(web app 1-test)을 다시 스왑하면 이전 버전으로 빠르게 되돌릴 수 있습니다. Azure Portal에서 스왑 시 소스 슬롯과 대상 슬롯을 반대로 지정하여 역방향 스왑을 수행할 수 있습니다.)

문제 94

contoso.com이라는 Azure Active Directory 테넌트에 다음과 같은 사용자가 있습니다.

user1: Cloud device administrator
user2: User administrator

contoso.com에는 다음과 같은 Windows 10 장치가 있습니다.

device1: Azure AD registered
device2: Azure AD joined

contoso.com에 다음과 같은 보안 그룹을 만듭니다.

group1: Assigned membership type, Owner = user2
group2: Dynamic device membership type, Owner = user2

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

user1은 group1에 device2를 추가할 수 있습니다.
user2는 group1에 device1을 추가할 수 있습니다.
user2는 group2에 device2를 추가할 수 있습니다.

해설:

이 문제는 Azure Active Directory 역할, 그룹 유형, 장치 등록 상태를 조합해서
누가 어떤 작업을 할 수 있는지를 이해하고 있는지를 테스트하는 구성입니다.

🎯 주요 전제 요약

사용자 역할:

user1: Cloud Device Administrator
user2: User Administrator, 그룹의 Owner

장치 상태:

device1: Azure AD Registered (개인 디바이스 – BYOD)
device2: Azure AD Joined (조직 디바이스 – Intune 관리 가능)

그룹 정보:

그룹	유형	Owner
group1	Assigned (수동 추가)	user2
group2	Dynamic device (조건 기반 자동 추가)	user2

✅ 정답 판별

✅ Q1: user1은 group1에 device2를 추가할 수 있습니다. → ❌ 거짓

**user1은 장치 관리 권한(CDA)**만 있음
Azure AD 그룹에 디바이스를 수동 추가할 권한은 없음
그룹 멤버십 추가는 User administrator or Group administrator 권한이 필요
게다가 그룹 Owner가 user2이기 때문에 user1은 권한 없음

🔻 결론: 거짓

✅ Q2: user2는 group1에 device1을 추가할 수 있습니다. → ✅ 참

group1은 Assigned 그룹
user2는 해당 그룹의 Owner
group1에 장치를 직접 수동 추가할 수 있음
device1이 Azure AD registered든 joined든 상관없이 수동 추가는 가능

🔻 결론: 참

✅ Q3: user2는 group2에 device2를 추가할 수 있습니다. → ❌ 거짓

group2는 Dynamic Device 그룹
동적 그룹은 조건에 맞는 장치만 자동 포함됨
수동 추가가 불가능
group Owner라도 장치를 직접 추가할 수단이 없음

🔻 결론: 거짓

✅ 최종 정답 요약:

설명 항목	정답
user1은 group1에 device2를 추가할 수 있습니다.	❌ 거짓
user2는 group1에 device1을 추가할 수 있습니다.	✅ 참
user2는 group2에 device2를 추가할 수 있습니다.	❌ 거짓

Azure AD registered: 개인 장치를 회사 계정에 연결한 상태입니다.
Azure AD joined: 회사 소유 장치를 Azure AD에 직접 연결한 상태입니다.
보안 그룹 (Security Group): 사용자 또는 장치들을 모아서 권한을 할당하거나 관리하는 데 사용됩니다.
Assigned membership type: 그룹 소유자 또는 지정된 관리자가 직접 구성원을 추가해야 하는 그룹입니다.
Dynamic device membership type: 장치 속성을 기반으로 그룹 구성원이 자동으로 결정되는 그룹입니다.
Owner: 그룹을 관리하고 구성원을 변경할 수 있는 사용자입니다.
Cloud device administrator: Azure AD에 등록되거나 조인된 장치를 관리할 수 있는 역할이지만, 그룹 구성원을 직접 변경할 권한은 없을 수 있습니다.
User administrator: 사용자를 생성, 관리하고 그룹 구성원을 변경할 수 있는 역할입니다.

정답:

user1은 group1에 device2를 추가할 수 있습니까? 아니요. (Cloud device administrator 역할은 조인된 장치를 관리할 수 있지만, 그룹 구성원을 추가할 권한은 없을 수 있습니다.)
user2는 group1에 device1을 추가할 수 있습니까? 예. (user2는 group1의 소유자이므로 구성원을 추가할 수 있습니다.)
user2는 group2에 device2를 추가할 수 있습니까? 아니요. (group2는 동적 그룹이므로 소유자가 수동으로 구성원을 변경할 수 없습니다. 장치 속성에 따라 자동으로 결정됩니다.)

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

가상 머신(VM) 관련 문제 분석 (0)	2025.04.28
AZ-104 시험 대비 문제 we-part2 (0)	2025.04.22
AZ-104 시험 대비 문제 we-part3 (0)	2025.04.22
Azure 주요 용어들의 상관 관계 (0)	2025.04.21
AZ104 예제 문제 "Deploy and manage Azure compute resources (20–25%)" 3 (0)	2025.04.21

내 블로그 - 관리자 홈 전환	`Q` `Q`
새 글 쓰기	`W` `W`

글 수정 (권한 있는 경우)	`E` `E`
댓글 영역으로 이동	`C` `C`

이 페이지의 URL 복사	`S` `S`
맨 위로 이동	`T` `T`
티스토리 홈 이동	`H` `H`
단축키 안내	`Shift` + `/` `⇧` + `/`

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

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

1. User Access Administrator (범위: lb1 리소스)

2. Virtual Machine Contributor (범위: 리소스 그룹)

✅ 해결 방법 요약

방법 1: Azure CLI로 약관 수락

방법 2: Azure Portal에서 수락

방법 3: PowerShell로 약관 수락

🔒 주의 사항: 누가 이 작업을 할 수 있는가?

정리

VNET1

VNET2

🎯 조건 요약

✅ 정책: "태그 및 기본값 적용" 작동 방식

🔎 각 리소스에 태그 적용 분석

📌 vnet1

📌 vnet2

✅ 최종 정리

✅ 조직적인 Azure 태그 관리를 위한 권장 설계 패턴

1. 정책 기반 태그 강제 적용 (Azure Policy)

대표 정책 종류:

2. 리소스 계층별 정책 범위 설계

3. 자동화 스크립트와 템플릿에 태그 포함

4. 권한 분리와 책임 역할 정의

5. 정기적 태그 감시 및 보고 자동화

🎯 최적 조합 예시

✅ 질문 분석

🎯 정답: D. Storage Blob Data Contributor

📌 이유:

✅ 할당 예시 (Azure CLI)

✅ 정답: D. group1, group2 및 group3 만

📌 Azure AD 그룹에 라이선스를 할당할 수 있는 조건

📌 보기별 검토

📎 공식 문서 참고

✅ 정답: D. device1, device2 및 device3

🎯 AzCopy란?

✅ 지원 운영체제 (공식)

📥 설치 예시

✅ Windows (device1)

✅ Linux (device2)

✅ macOS (device3)

✅ 결론

🎯 정답: rule2 - Blob 삭제

🔍 조건 정리

✅ Azure 정책 충돌 시 처리 방식

하지만 중요한 원칙은: 하나의 Blob에 대해 여러 작업이 동시에 조건을 만족해도, 실제로는 하나의 작업만 적용됨이 경우, "삭제 작업이 가장 우선시" 됩니다.이건 문서나 실제 실험에서 검증된 내용입니다.

✅ rule2가 적용되는 이유

🔚 최종 결론

🔹 문장 완성

✅ 상세 분석

✅ 정답: B. instance3 및 instance4 만

🔍 핵심 개념: 컨테이너 그룹의 OS 혼합 불가

❗ 컨테이너 그룹 제약 조건

🎯 보기 분석

✅ 따라서

✅ 정답

🔍 해설

1️⃣ 최소 복제본 수: 3개

2️⃣ 자주 액세스하지 않는 데이터의 비용 절감

💡 부가 팁

✅ 정답: D. Azure Data Box Heavy

🔍 선택 이유

❌ 오답 분석

A. Azure Portal을 사용한 업로드

B. Azure Data Box Edge

C. Azure Import/Export

✅ 정답: C. 슬롯 스왑 (Swap the slots)

🔍 이유

🔄 슬롯 스왑(Swap the slots)

❌ 오답 분석

A. app1 복제 (Clone)

B. app1 재배포 (Redeploy)

D. app1 백업 복원 (Restore the backup of app1)

🎯 주요 전제 요약

사용자 역할:

장치 상태:

그룹 정보:

✅ 정답 판별

✅ Q1: user1은 group1에 device2를 추가할 수 있습니다. → ❌ 거짓

✅ Q2: user2는 group1에 device1을 추가할 수 있습니다. → ✅ 참

하지만 중요한 원칙은:
하나의 Blob에 대해 여러 작업이 동시에 조건을 만족해도, 실제로는 하나의 작업만 적용됨
이 경우, "삭제 작업이 가장 우선시" 됩니다.이건 문서나 실제 실험에서 검증된 내용입니다.