🎯 AZ-104: Microsoft Azure Administrator

📚 해설

Box 1: 아니오

• User1은 cloud-only 사용자입니다.
• Azure Files의 ID 기반 액세스는 하이브리드 사용자(온프레미스에서 동기화된 사용자)만 지원합니다.
• Cloud-only 사용자는 storage account key나 SAS 토큰을 사용해야 합니다.

Box 2: 예

• User2는 하이브리드 사용자(온프레미스에서 동기화됨)입니다.
• Kerberos 인증을 통해 Azure Files에 액세스할 수 있습니다.
• 적절한 NTFS 권한이 설정되어 있으면 액세스 가능합니다.

Box 3: 아니오

• User3은 guest 사용자입니다.
• Azure Files ID 기반 액세스는 guest 사용자를 지원하지 않습니다.
• 테넌트의 멤버 사용자만 지원됩니다.

📚 해설

User1이 share1에 액세스할 수 있습니까? - 예

• User1은 OU1에 속하고 Microsoft Entra Connect로 동기화됩니다.
• Group1에는 Storage File Data SMB Share Contributor 역할이 할당되어 있습니다.
• User1은 Group1의 구성원이므로 액세스 가능합니다.

User2가 share1에 액세스할 수 있습니까? - 아니오

• User2는 OU2에 속하고 동기화되지 않습니다.
• Microsoft Entra Connect는 OU1만 동기화하도록 구성되어 있습니다.
• 동기화되지 않은 사용자는 Azure Files에 액세스할 수 없습니다.

User3가 share1에 액세스할 수 있습니까? - 아니오

• User3은 클라우드 전용 사용자입니다.
• AD DS 기반 Azure Files는 온프레미스에서 동기화된 사용자만 지원합니다.
• Cloud-only 사용자는 storage account key를 사용해야 합니다.

📚 해설

ZRS 변환 요구사항:

• 계정 유형: General Purpose v2 (GPv2) 또는 BlockBlobStorage
• 성능 계층: Standard 또는 Premium
• 현재 복제: LRS, GRS, RA-GRS에서 변환 가능
• 지역 지원: ZRS를 지원하는 지역이어야 함

분석:

• storage1: GPv2, Standard, LRS → ZRS 변환 가능
• storage2: FileStorage 계정 → ZRS 변환 불가
• storage3: BlockBlobStorage, Premium → 일부 제한 있음

변환 방법:

• Azure Portal에서 Configuration → Replication
• 실시간 마이그레이션 또는 수동 마이그레이션
• 다운타임 없이 변환 가능

📚 해설

왜 B가 정답인가:

• Reader and Data Access 역할은 스토리지 데이터에 대한 읽기 권한만 제공합니다.
• 스토리지 계정 키를 나열하거나 재생성하는 권한은 포함되지 않습니다.
• 이 역할은 blob, queue, table 데이터에 대한 읽기 액세스만 허용합니다.

올바른 솔루션:

• Storage Account Key Operator Service Role - 키 관리 전용
• Storage Account Contributor - 전체 스토리지 계정 관리
• Contributor - 리소스 그룹 수준에서 할당

필요한 권한:

• Microsoft.Storage/storageAccounts/listkeys/action - 키 나열
• Microsoft.Storage/storageAccounts/regeneratekey/action - 키 재생성

📚 해설

Azure Container Registry SKU별 기능:

• Basic: 개발용, 지역 복제 지원 안함
• Standard: 향상된 처리량, 지역 복제 지원 안함
• Premium: 최고 성능, 지역 복제 지원

지역 복제 (Geo-replication) 요구사항:

• Premium SKU가 필수 조건입니다.
• 여러 Azure 지역에 레지스트리 복제본 생성
• 네트워크 근접성을 통한 빠른 이미지 풀
• 지역별 장애 조치 지원

업그레이드 절차:

1. Azure Portal에서 Container Registry 선택
2. Settings → Configuration
3. SKU를 Premium으로 변경
4. 지역 복제 구성 가능

📚 해설

Azure Blob Storage 액세스 정책 제한:

• 최대 저장된 액세스 정책: 컨테이너당 5개
• 이미 생성된 정책: Stored1, Stored2, Stored3 (3개)
• 추가 가능한 정책: 5 - 3 = 2개

저장된 액세스 정책의 이점:

• SAS 토큰의 중앙 집중식 관리
• 정책 수정 시 SAS 토큰 자동 업데이트
• 정책 철회를 통한 즉시 액세스 차단
• 권한, 시작/만료 시간 제어

Legal Hold와의 관계:

• Legal Hold는 액세스 정책 제한에 영향을 주지 않습니다.
• 불변 스토리지 정책은 별도로 관리됩니다.

📚 해설

Azure Disk Encryption 요구사항:

• Key Vault 위치: VM과 동일한 지역 및 구독
• VM 크기: 최소 7GB RAM (KEK 사용 시)
• OS 지원: Windows/Linux 특정 버전
• 디스크 유형: Managed Disk 권장

Case Study 분석:

• Vault1: Key Vault (KEK 지원)
• VM2: 암호화 요구사항 충족
• VM3: 암호화 요구사항 충족
• 기타 VM: 요구사항 불충족

KEK(Key Encryption Key) 이점:

• 이중 암호화 보안
• 키 관리의 중앙 집중화
• 규정 준수 요구사항 충족
• 키 회전 지원

📚 해설

디렉터리 구조 지원:

• Blob Storage: 가상 디렉터리 구조 지원
• Azure Files: 실제 디렉터리 구조 지원
• Queue/Table Storage: 디렉터리 구조 미지원

제외되는 이유:

• cont2: Legal Hold와 Immutable 정책이 적용됨
• 불변 정책이 적용된 컨테이너는 구조 변경 제한
• 기존 블롭의 메타데이터 수정 불가

Azure Files vs Blob Storage 디렉터리:

• Azure Files: SMB/NFS 프로토콜, 실제 폴더
• Blob Storage: REST API, 가상 폴더 (prefix 기반)
• 조직 방법: 계층적 네임스페이스 사용

📚 해설

RBAC 상속 원칙:

• 역할 할당은 상위 범위에서 하위 범위로 상속됩니다.
• 구독 → 리소스 그룹 → 리소스 순서로 상속
• 명시적 거부가 없는 한 상속된 권한이 적용됩니다.

역할별 권한:

• Owner: 모든 리소스에 대한 전체 액세스
• Contributor: 리소스 생성/관리, 역할 할당 제외
• Reader: 리소스 보기만 가능

분석 방법:

1. 각 사용자의 역할 할당 범위 확인
2. 상속 관계 분석
3. 실제 유효 권한 계산
4. 구독별 접근 권한 확인

📚 해설

Private Endpoint의 역할:

• Azure 서비스에 대한 프라이빗 연결 제공
• 트래픽이 Microsoft 백본 네트워크를 통해서만 이동
• 공용 인터넷을 통하지 않는 보안 연결
• VNet 내부의 프라이빗 IP 주소 사용

다른 옵션이 부적절한 이유:

• NSG: 트래픽 필터링만 수행, 경로 변경 불가
• Application Proxy: 온프레미스 앱의 외부 액세스용
• Virtual WAN: 네트워크 연결 최적화, 백본 보장 안함

구현 방법:

1. Storage Account에 Private Endpoint 생성
2. VM1의 VNet과 연결
3. Private DNS Zone 구성
4. 공용 액세스 비활성화

📚 해설

C. 동적 사용자 구성원 유형을 사용하는 그룹을 만듭니다:

• 사용자 속성(부서)을 기반으로 자동 그룹 할당
• 규칙 기반 구성원 관리로 관리 노력 최소화
• 예시 규칙: (user.department -eq "IT")

F. 사용자 정보와 적절한 특성이 포함된 CSV 파일을 만듭니다:

• Microsoft Entra ID 대량 가져오기는 CSV 형식 사용
• 부서 정보를 department 속성에 포함
• 표준화된 가져오기 프로세스

동적 그룹 규칙 예시:

• IT 부서: (user.department -eq "IT")
• HR 부서: (user.department -eq "HR")
• Finance 부서: (user.department -eq "Finance")

왜 다른 옵션이 틀렸는가:

• A: 수동 관리 필요
• D: 추가 스크립트 복잡성
• E: Azure AD는 CSV만 지원

📚 해설

Azure Key Vault의 키 회전 기능:

• 스토리지 계정 키의 자동 회전 지원
• 사용자 정의 회전 주기 설정 가능
• 안전한 키 저장 및 관리
• 애플리케이션에 투명한 키 업데이트

구성 방법:

1. Key Vault 생성 또는 기존 사용
2. Storage Account와 Key Vault 연결
3. Key Vault에 Storage Account Key 추가
4. 자동 회전 정책 설정
5. 회전 주기 정의 (예: 90일)

다른 옵션이 부적절한 이유:

• 백업/Recovery 자격 증명 모음: 백업 전용
• 중복성: 데이터 복제 설정
• 수명 주기 관리: 데이터 계층화/삭제

보안 이점:

• 정기적인 키 변경으로 보안 강화
• 키 노출 위험 최소화
• 중앙 집중식 키 관리

📚 해설

SSPR 활성화 대상:

• None: 모든 사용자에 대해 비활성화
• Selected: 특정 보안 그룹에 대해서만 활성화
• All: 모든 사용자에 대해 활성화

개별 사용자 vs 그룹:

• Azure Portal에서는 개별 사용자에게 직접 SSPR을 할당할 수 없습니다.
• 반드시 보안 그룹을 통해서만 할당 가능합니다.
• Microsoft 365 그룹이나 메일 그룹은 사용할 수 없습니다.

표 분석 (추정):

• User1: 개별 사용자 → SSPR 직접 할당 불가
• Group1: 보안 그룹 → SSPR 할당 가능
• Group2: 보안 그룹 → SSPR 할당 가능

구성 방법:

1. Azure AD → Password reset
2. Properties → Selected
3. 보안 그룹 선택
4. 인증 방법 구성

📚 해설

그룹 명명 정책 구성 순서:

1. Groups 블레이드로 이동
2. Naming policy 선택
3. Group naming policy 구성

명명 정책 구성 요소:

• Prefix: 그룹 이름 앞에 추가될 텍스트
• Suffix: 그룹 이름 뒤에 추가될 텍스트
• Attributes: 사용자 속성 기반 동적 값
• Blocked words: 사용할 수 없는 단어 목록

동적 속성 예시:

• [Department]: 사용자의 부서
• [Company]: 회사명
• [Office]: 사무실 위치
• [CountryOrRegion]: 국가/지역

예시 형식: Contoso_[Department]_Group

📚 해설

사용자 삭제 제한사항:

• 글로벌 관리자: 마지막 글로벌 관리자는 삭제 불가
• 동기화된 사용자: 온프레미스에서만 삭제 가능
• 활성 할당: 중요한 역할 할당이 있는 경우 주의

그룹 삭제 제한사항:

• 시스템 그룹: Azure AD 기본 그룹은 삭제 불가
• 동기화된 그룹: 온프레미스에서만 삭제 가능
• 역할 할당 그룹: 중요한 권한이 있는 그룹 주의

삭제 전 확인사항:

• 중요한 리소스에 대한 액세스 권한
• 다른 사용자/그룹에 미치는 영향
• 백업 관리자 계정 존재 여부
• 비즈니스 연속성 영향

📚 해설

App Service의 Key Vault 액세스:

• Managed Identity: 가장 안전한 인증 방법
• 암호나 인증서 관리 불필요
• Azure AD에서 자동으로 관리되는 ID
• System-assigned 또는 User-assigned 선택 가능

Key Vault 지역 제한:

• App Service와 Key Vault는 동일한 지역에 있어야 합니다.
• 네트워크 지연 시간 최소화
• 데이터 상주 요구사항 충족
• 재해 복구 시나리오 고려

구성 단계:

1. App Service에서 Managed Identity 활성화
2. Key Vault 액세스 정책에 Identity 추가
3. 필요한 권한 부여 (Get, List secrets)
4. 앱 코드에서 Azure SDK 사용

📚 해설

협업 제한 설정의 역할:

• 특정 도메인으로만 초대 제한
• 허용 목록 또는 차단 목록 구성
• B2B 게스트 초대 정책 제어
• 보안 및 거버넌스 강화

구성 방법:

1. Azure AD → External Identities
2. External collaboration settings
3. Collaboration restrictions
4. "Allow invitations only to the specified domains"
5. fabrikam.com 도메인 추가

다른 설정의 목적:

• 테넌트 제한: 액세스 제어, 초대 제한 아님
• Microsoft 클라우드 설정: 클라우드 환경 구성
• 게스트 액세스 제한: 권한 수준 제어

보안 이점:

• 승인되지 않은 도메인으로부터 보호
• 데이터 유출 위험 감소
• 거버넌스 정책 준수

📚 해설

조건부 역할 할당 지원:

• Azure RBAC에서 일부 역할만 조건부 할당 지원
• 주로 데이터 플레인 역할에서 지원
• Storage Blob Data 관련 역할이 대표적

D. Storage Blob Data Contributor:

• Blob 데이터 읽기, 쓰기, 삭제 권한
• 조건부 할당 지원
• 컨테이너별, blob별 세밀한 제어 가능
• POSIX ACL 설정 권한 없음

E. Storage Blob Data Owner:

• Blob Data Contributor의 모든 권한
• POSIX ACL 설정 권한 추가
• 조건부 할당 지원
• 소유권 관리 기능

조건 예시:

• 특정 컨테이너에만 액세스
• 특정 시간대에만 액세스
• 특정 IP 범위에서만 액세스
• 특정 태그가 있는 blob만 액세스

📚 해설

Azure Container Instances 리소스 관리:

• 컨테이너 그룹 내 컨테이너들은 전체 리소스 풀 공유
• 개별 컨테이너의 리소스 제한은 최대 사용량 제한
• 제한이 없으면 필요에 따라 동적으로 리소스 사용

현재 상황 분석:

• 각 컨테이너에 CPU 제한이 설정되어 있음
• 제한으로 인해 container2가 추가 CPU 사용 불가
• container1이 사용하지 않는 CPU도 container2가 활용 불가

리소스 제한 제거의 효과:

• 컨테이너들이 필요에 따라 CPU 리소스 공유
• container1이 유휴 상태일 때 container2가 더 많은 CPU 사용
• 동적 리소스 할당으로 효율성 향상
• Linux 스케줄러가 공정한 배분 보장

왜 다른 옵션이 부적절한가:

• A, B: 여전히 제한이 존재하여 유연성 부족
• D: container2의 리소스를 더 제한하여 문제 악화

📚 해설

Azure Container Apps 자동 확장:

• KEDA 기반 이벤트 기반 자동 확장
• HTTP 요청, 큐 길이, CPU/메모리 기반 확장
• 0에서 N까지 동적 확장 (서버리스)
• 마이크로서비스 아키텍처에 최적화

Azure App Service 자동 확장:

• CPU, 메모리, HTTP 큐 기반 확장
• 예약된 시간 기반 확장
• 커스텀 메트릭 기반 확장
• 컨테이너 이미지 배포 지원

Azure Container Instances:

• 자동 확장 기능 없음
• 단일 컨테이너 또는 컨테이너 그룹
• 수동 확장만 가능
• 간단한 워크로드용

자동 확장 시나리오:

• 트래픽 급증 대응
• 비용 최적화 (사용량 기반)
• 고가용성 보장
• 성능 요구사항 충족

📚 해설

Azure Container Registry 생성:

• 명령: az acr create
• 리소스 그룹, 이름, SKU 지정 필요
• Basic, Standard, Premium SKU 선택 가능
• 지역 지정 필수

이미지를 레지스트리에 푸시:

• 명령: az acr build 또는 docker push
• az acr build: 클라우드에서 빌드 및 푸시
• docker push: 로컬 이미지를 레지스트리에 푸시
• 사전에 az acr login 필요

명령 시퀀스:

1. az acr create --name myregistry --resource-group myRG --sku Basic
2. az acr login --name myregistry
3. docker tag image1 myregistry.azurecr.io/image1
4. docker push myregistry.azurecr.io/image1

대안 방법 (az acr build):

• 로컬 Docker 불필요
• 클라우드에서 직접 빌드
• 소스 코드에서 바로 이미지 생성

📚 해설

왜 B가 정답인가:

• ACR-Tasks-Network는 ACR Tasks의 네트워크 관련 서비스 주체입니다.
• Container Instances 배포와는 직접적인 관련이 없습니다.
• Container Instance가 이미지를 풀하는 데 필요한 권한과 무관합니다.

올바른 솔루션:

• Admin User 활성화: Registry에서 admin 계정 사용
• Service Principal: Container Instance용 서비스 주체 생성
• Managed Identity: Container Instance에 관리 ID 할당
• Azure Container Instance Service: 해당 서비스에 AcrPull 역할 할당

일반적인 배포 오류 원인:

• 레지스트리 접근 권한 부족
• 이미지 이름/태그 오류
• 네트워크 연결 문제
• 리소스 할당량 초과

📚 해설

전용 데이터 엔드포인트의 목적:

• 방화벽 환경에서의 네트워크 규칙 간소화
• 관리 트래픽과 데이터 트래픽 분리
• 더 세밀한 네트워크 제어
• 인증 문제 해결에는 무관

컨테이너 배포 실패의 주요 원인:

• 인증 권한 부족 - 가장 일반적인 원인
• 이미지 이름/경로 오류
• 네트워크 접근 제한
• 리소스 제한

전용 데이터 엔드포인트 vs 인증:

• 전용 엔드포인트: 네트워크 수준 최적화
• 배포 실패: 주로 권한/인증 문제
• 서로 다른 계층의 문제

📚 해설

프라이빗 엔드포인트의 역할:

• 네트워크 격리 및 보안 강화
• VNet 내부에서만 레지스트리 접근
• 공용 인터넷 트래픽 차단
• 인증/권한 문제는 해결하지 않음

Container Instance 배포 실패 근본 원인:

• 레지스트리 접근 권한 부족
• 적절한 인증 메커니즘 부재
• Admin user 비활성화 상태
• Service Principal 권한 부족

올바른 해결 방법:

1. Admin User 활성화 및 자격 증명 사용
2. Container Instance에 Managed Identity 할당
3. Service Principal 생성 및 AcrPull 역할 할당
4. 적절한 인증 정보를 배포 시 제공

네트워크 vs 인증:

• 프라이빗 엔드포인트: 네트워크 보안
• 배포 실패: 인증/권한 문제
• 두 가지는 독립적인 보안 계층

📚 해설

App Service 확장 방법:

• Scale up: 더 강력한 하드웨어로 업그레이드
• Scale out: 동일한 인스턴스를 더 많이 추가
• CPU 기반 자동 확장은 Scale out에 해당

Rules Based 자동 확장:

• 메트릭 기반 확장 규칙 정의
• CPU, 메모리, HTTP 큐 길이 등 모니터링
• 임계값 도달 시 인스턴스 추가/제거
• 최소/최대 인스턴스 수 설정 가능

CPU 80% 규칙 설정:

1. App Service Plan → Scale out
2. Rules Based 선택
3. Add a rule
4. Metric: CPU Percentage
5. Threshold: 80%
6. Action: Increase count by 1

다른 옵션이 부적절한 이유:

• A (Automatic): 기본 메트릭만 사용, 세밀한 제어 불가
• C, D: Scale up은 하드웨어 업그레이드
• E (Manual): 수동 확장, 자동화 없음

📚 해설

App Service TLS 인증서 요구사항:

• PFX 형식이어야 함 (개인 키 포함)
• 2048비트 이상의 RSA 키
• 중간 인증서 포함된 전체 체인
• 유효한 만료 날짜

Key Vault 인증서 분석 (Case Study 기반):

• Cert1: 개인 키 포함, App Service 호환
• Cert2: 개인 키 포함, App Service 호환
• Cert3: 공개 키만 또는 형식 부적합
• Cert4: 공개 키만 또는 형식 부적합

Key Vault와 App Service 통합:

1. App Service에 Managed Identity 할당
2. Key Vault 액세스 정책에 Get Certificates 권한 부여
3. App Service → TLS/SSL settings
4. Private Key Certificates에서 Key Vault 인증서 가져오기

TLS 구성 이점:

• 데이터 전송 암호화
• 브라우저 신뢰성 확보
• SEO 및 보안 규정 준수
• Key Vault를 통한 중앙 집중식 인증서 관리

📚 해설

왜 B가 정답인가:

• 구독 간 이동은 VM을 다른 물리적 호스트로 이동시키지 않습니다.
• 단순히 Azure 관리 및 청구 컨텍스트만 변경됩니다.
• VM은 여전히 동일한 물리적 서버에서 실행됩니다.
• 유지 관리 문제가 해결되지 않습니다.

올바른 솔루션:

• VM Redeploy: VM1 → Operations → Redeploy + reapply
• VM을 새로운 Azure 호스트로 이동
• 유지 관리 영향 즉시 회피
• 애플리케이션 상태 보존

Redeploy vs 다른 방법들:

• Redeploy: 즉시 호스트 변경
• 구독 이동: 관리 컨텍스트만 변경
• Restart: 동일 호스트에서 재시작
• Stop/Start: 호스트 변경 가능하지만 보장 안됨

유지 관리 시나리오:

• Azure 호스트 하드웨어 업데이트
• 보안 패치 적용
• 인프라 업그레이드
• 예정된 다운타임 회피

📚 해설

VM Redeploy의 효과:

• VM을 새로운 Azure 호스트로 즉시 이동
• 유지 관리 영향을 받지 않는 다른 물리적 서버로 이전
• VM 상태와 데이터 보존
• 임시 IP 주소는 변경될 수 있음

Redeploy 과정:

1. 현재 호스트에서 VM 일시 중지
2. 새로운 Azure 호스트 선택
3. VM 메타데이터 및 디스크 연결
4. 새 호스트에서 VM 재시작

유지 관리 회피 전략:

• Proactive: 유지 관리 알림 수신 시 즉시 Redeploy
• Reactive: 유지 관리 중 자동 이동 대기
• Redeploy는 proactive 접근법으로 다운타임 최소화

주의사항:

• Redeploy 중 짧은 다운타임 발생
• 임시 IP 주소 변경 가능 (정적 IP 권장)
• 확장 프로그램 재구성 필요할 수 있음
• 로컬 임시 디스크 데이터 손실