🎯 AZ-104: Microsoft Azure Administrator

📚 해설

왜 D가 정답인가:

• VM 템플릿에서 배포할 때 리소스 그룹은 배포 시점에 지정할 수 있습니다.
• 운영체제, VM 크기, 관리자 사용자명은 템플릿에 미리 정의되어 있습니다.

다른 옵션이 틀린 이유:

• A: 운영체제는 템플릿에 고정되어 있음
• B: 관리자 사용자명도 템플릿에 정의됨
• C: VM 크기도 템플릿에서 미리 설정됨

📚 해설

왜 B가 정답인가:

• 앱이 여러 인스턴스를 지원하지 않으므로 스케일 아웃이 불가능합니다.
• 단일 VM의 성능을 향상시키려면 VM 크기를 더 큰 크기로 변경해야 합니다.
• runbook을 통해 자동으로 VM 크기를 조정할 수 있습니다.

다른 옵션이 틀린 이유:

• A: 진단 에이전트는 성능 향상에 도움이 되지 않음
• C: 앱이 여러 인스턴스를 지원하지 않음
• D: 할당량 증가만으로는 성능이 향상되지 않음
• E: DSC는 구성 관리용이지 성능 향상용이 아님

📚 해설

왜 B가 정답인가:

• DSC 확장은 VM에 소프트웨어를 설치하고 구성하는 표준 방법입니다.
• 가상 머신 스케일 셋의 모든 인스턴스에 일관되게 NGINX를 설치할 수 있습니다.
• ARM 템플릿에서 DSC 확장을 정의하여 자동화할 수 있습니다.

다른 옵션이 틀린 이유:

• A: Deployment Center는 App Service용이지 VM용이 아님
• C: 이 cmdlet은 Azure Policy 구성용
• D: Intune은 모바일 장치 관리용

📚 해설

Box 1: 10.244.0.0/16

• Pod CIDR 범위입니다.
• --pod-cidr은 네트워크 환경의 다른 곳에서 사용하지 않는 큰 주소 공간이어야 합니다.
• Express Route 또는 Site-to-Site VPN 연결을 통해 연결할 온프레미스 네트워크 범위를 포함합니다.

Box 2: 10.0.0.0/16

• --service-cidr은 AKS 클러스터의 내부 서비스에 IP 주소를 할당하는 데 사용됩니다.
• 이 범위는 클러스터 내에서만 사용되며 외부에서 라우팅되지 않습니다.

📚 해설

Box 1: 5

• CPU 사용률이 30% 이상이므로 최대 5개의 인스턴스가 유지됩니다.
• 스케일 아웃 조건이 충족되어 최대 인스턴스 수까지 확장됩니다.

Box 2: 3

• 평균 CPU 사용률이 30% 아래로 떨어지면 개수가 1씩 감소합니다.
• 5분 쿨다운 후 또 다른 1개가 감소하여 3개에 도달합니다.
• 최소 인스턴스 수 제한에 의해 더 이상 감소하지 않습니다.

📚 해설

왜 C가 정답인가:

• D 드라이브는 임시 디스크로, VM 재배포 시 데이터가 손실됩니다.
• Azure VM의 임시 디스크는 로컬 SSD 저장소를 사용하며 영구적이지 않습니다.

다른 옵션이 틀린 이유:

• A, B: 사용자 설정은 사용자 프로필에 저장되어 C 드라이브에 보존됨
• D: C 드라이브는 OS 디스크로 영구 저장소이므로 재배포 후에도 유지됨

Azure VM 디스크 유형:

• C 드라이브: OS 디스크 (영구)
• D 드라이브: 임시 디스크 (일시적)

📚 해설

왜 C가 정답인가:

• 온프레미스 Hyper-V VM을 Azure로 마이그레이션하려면 디스크 형식을 VHD로 변환해야 합니다.
• Azure는 VHD 형식만 지원하므로 하드 드라이브 설정을 수정해야 합니다.
• 동적 디스크가 있다면 기본 디스크로 변환해야 할 수도 있습니다.

Azure 마이그레이션 요구사항:

• 디스크 형식: VHD (VHDX 불가)
• 디스크 유형: 기본 디스크 (동적 디스크 불가)
• 부팅 파티션: MBR 또는 GPT

📚 해설

스케일 셋 인스턴스 분석:

Box 1: 4

• 현재 실행 중인 인스턴스 수는 4개입니다.
• get-azvmss 명령어 결과에서 확인할 수 있습니다.

Box 2: Standard_D1_v2

• 모든 인스턴스는 동일한 VM 크기를 사용합니다.
• 스케일 셋의 모든 인스턴스는 동일한 구성을 가져야 합니다.

📚 해설

왜 B가 정답인가:

• ARM 템플릿 배포 기록은 리소스 그룹 수준에서 관리됩니다.
• 리소스 그룹의 "배포" 섹션에서 과거 템플릿 배포 내역을 확인할 수 있습니다.
• 여러 리소스가 함께 배포된 경우 리소스 그룹에서 전체 배포 정보를 볼 수 있습니다.

배포 기록 확인 방법:

1. Azure Portal에서 RG1 리소스 그룹으로 이동
2. "배포" 또는 "Deployments" 메뉴 선택
3. 배포 목록에서 해당 배포 선택
4. "템플릿" 탭에서 사용된 ARM 템플릿 확인

📚 해설

왜 B가 정답인가:

• 배포 슬롯 교체는 즉시 되돌릴 수 있는 기능입니다.
• 이미 webapp1-test와 webapp1-prod를 교체했으므로, 다시 교체하면 원래 상태로 돌아갑니다.
• 슬롯 교체는 몇 초 내에 완료되는 가장 빠른 방법입니다.

다른 옵션이 틀린 이유:

• A: 재배포는 시간이 오래 걸림
• C: 복제는 새로운 앱을 만드는 것으로 되돌리기가 아님
• D: 백업 복원도 시간이 오래 걸리고 데이터 손실 가능성

배포 슬롯의 장점:

• 무중단 배포 가능
• 즉시 롤백 가능
• 프로덕션 환경에서 실제 테스트 가능

📚 해설

VM 백업 복원 옵션:

첫 번째 옵션: 새 VM 생성

• Azure Backup은 백업 데이터로부터 새로운 VM을 생성할 수 있습니다.
• 랜섬웨어로 감염된 원본 VM과 별도로 깨끗한 VM을 생성합니다.

두 번째 옵션: 기존 VM 디스크 교체

• 기존 VM의 디스크를 백업된 디스크로 교체할 수 있습니다.
• VM 구성은 유지하면서 디스크만 복원된 것으로 교체합니다.

세 번째 옵션: 디스크만 복원

• 백업에서 디스크만 복원하여 별도 관리할 수 있습니다.
• 필요에 따라 나중에 이 디스크를 사용하여 VM을 생성할 수 있습니다.

📚 해설

왜 B가 정답인가:

• Azure VM Agent는 백업 작업에 필수적인 구성 요소입니다.
• 오래된 VM Agent 버전은 백업 기능과 호환성 문제를 일으킬 수 있습니다.
• Warning 상태는 백업이 가능하지만 최적이 아닌 상태를 나타냅니다.

Azure VM Agent의 역할:

• 백업 확장 프로그램과 상호 작용
• VM 내부에서 백업 작업 조정
• 스냅샷 생성 및 관리

다른 옵션이 틀린 이유:

• A: VM이 중지되어도 백업 가능 (Error가 아닌 Warning)
• C: 관리되지 않는 디스크도 백업 가능
• D: 자격 증명 모음이 없으면 Error 상태

📚 해설

왜 B가 정답인가:

• 리소스 그룹 이동은 VM을 다른 물리적 호스트로 이동시키지 않습니다.
• 리소스 그룹 이동은 단순히 Azure 리소스 관리 계층의 논리적 이동입니다.
• VM을 다른 호스트로 이동하려면 VM을 중지했다가 다시 시작해야 합니다.

올바른 솔루션:

• VM 재시작: VM을 중지하고 다시 시작
• VM 재배포: Azure Portal에서 "재배포" 옵션 사용
• VM 이동: 다른 지역이나 가용성 영역으로 이동

유지 관리 시나리오:

• Azure는 때때로 물리적 호스트 유지 관리를 수행합니다.
• 계획된 유지 관리 알림을 받으면 미리 대응할 수 있습니다.

📚 해설

왜 C가 정답인가:

• Azure Import/Export 서비스는 Azure Blob Storage와 Azure Files만 지원합니다.
• 5TB와 같은 대용량 데이터를 물리적 디스크를 통해 전송할 때 사용합니다.
• 인터넷 업로드보다 빠르고 비용 효율적인 방법입니다.

Azure Import/Export 지원 대상:

• Import: Azure Blob Storage, Azure Files
• Export: Azure Blob Storage만 지원

다른 옵션이 틀린 이유:

• A: Cosmos DB는 Import/Export 서비스 미지원
• B: Data Lake Store는 Import/Export 서비스 미지원
• D: Data Factory는 데이터 통합 서비스이지 저장소가 아님

사용 시나리오:

• 대용량 데이터 마이그레이션
• 느린 인터넷 연결 환경
• 비용 절약이 필요한 경우

📚 해설

왜 A가 정답인가:

• VM1이 West US 지역에 있으므로 NIC2도 같은 지역에 생성되어야 합니다.
• 리소스 그룹(RG1)은 네트워크 인터페이스를 생성할 수 있는 유효한 위치입니다.
• VM과 동일한 지역에 있으면 네트워크 인터페이스를 VM에 연결할 수 있습니다.

네트워크 인터페이스 요구사항:

• 지역 일치: VM과 동일한 Azure 지역
• 가상 네트워크: 동일한 VNet 또는 피어링된 VNet
• 구독: 동일한 구독 내

다중 NIC 시나리오:

• VM 크기가 다중 NIC를 지원해야 함
• 각 NIC는 서로 다른 서브넷에 연결 가능
• 네트워크 격리 및 보안 강화에 사용

📚 해설

왜 B가 정답인가:

• VM1이 West US에 있는데 NIC2를 Central US에 생성하려고 합니다.
• 네트워크 인터페이스는 VM과 동일한 Azure 지역에 있어야 합니다.
• 지역이 다르면 NIC를 VM에 연결할 수 없습니다.

Azure 지역 제약사항:

• VM과 NIC: 반드시 동일한 지역
• VNet과 NIC: 동일한 지역 내 VNet에 연결
• 크로스 리전: 직접 연결 불가능

리소스 그룹 vs 지역:

• 리소스 그룹(RG2)은 다른 그룹이어도 상관없음
• 하지만 지역(Central US vs West US)은 일치해야 함
• 리소스 그룹은 논리적 컨테이너일 뿐

📚 해설

왜 A가 정답인가:

• VM1과 NIC2가 모두 West US 지역에 있으므로 연결이 가능합니다.
• 다른 리소스 그룹(RG2)에 있어도 같은 구독 내이므로 문제없습니다.
• 지역이 일치하는 것이 가장 중요한 요구사항입니다.

리소스 그룹 독립성:

• 리소스 그룹은 관리 및 청구 단위일 뿐
• 다른 RG의 리소스 간 연결 가능
• 동일 구독 내에서는 자유로운 참조 가능

네트워크 인터페이스 생성 후:

1. VM 중지
2. NIC2를 VM에 연결
3. 네트워크 설정 구성
4. VM 시작

다중 NIC 활용:

• 프론트엔드/백엔드 네트워크 분리
• 관리 네트워크 분리
• 고가용성 구성

📚 해설

왜 D가 정답인가:

• 템플릿이 리소스 그룹을 생성하므로 구독 수준 배포가 필요합니다.
• New-AzDeployment는 구독 수준에서 ARM 템플릿을 배포하는 cmdlet입니다.
• 리소스 그룹 자체를 생성하는 템플릿은 구독 범위에서 실행되어야 합니다.

ARM 배포 범위별 cmdlet:

• 구독 수준: New-AzDeployment
• 리소스 그룹 수준: New-AzResourceGroupDeployment
• 관리 그룹 수준: New-AzManagementGroupDeployment
• 테넌트 수준: New-AzTenantDeployment

다른 옵션이 틀린 이유:

• A: 단일 리소스 생성용
• B: 기존 리소스 그룹 내 배포용
• C: 테넌트 전체 배포용

템플릿 특징:

• targetScope가 "subscription"으로 설정됨
• 리소스 그룹 생성 후 Storage 계정 생성

📚 해설

Box 1: Azure Storage 계정

• App Service 백업은 Azure Storage 계정을 대상으로 합니다.
• 백업 데이터는 Storage 계정의 컨테이너에 저장됩니다.
• 앱과 동일한 구독의 Storage 계정이어야 합니다.

Box 2: _backup.filter 파일

• 백업에서 파일과 폴더를 제외하는 데 사용되는 특수 파일입니다.
• D:\home\site\wwwroot 폴더에 생성해야 합니다.
• 제외할 파일과 폴더 목록을 이 파일에 지정합니다.

App Service 백업 구성 요소:

• 앱 구성: 설정 및 연결 문자열
• 파일 콘텐츠: 웹앱 파일 시스템
• 연결된 데이터베이스: SQL Database 등

_backup.filter 파일 예시:

\Folder2\
\logs\*.log
\temp\*

📚 해설

왜 C가 정답인가:

• Custom Script Extension은 VM 배포 후 스크립트를 실행하는 표준 방법입니다.
• NGINX 설치와 같은 소프트웨어 설치 작업에 적합합니다.
• ARM 템플릿에서 직접 정의하여 자동화할 수 있습니다.
• 가상 머신 스케일 셋의 모든 인스턴스에 동일하게 적용됩니다.

Custom Script Extension 장점:

• 유연성: PowerShell, Bash 스크립트 실행 가능
• 자동화: VM 생성과 동시에 실행
• 확장성: 스케일 셋의 모든 인스턴스에 적용
• 통합성: ARM 템플릿에 포함 가능

다른 옵션이 틀린 이유:

• A: DSC 구성 게시용 cmdlet이지 직접 설치용이 아님
• B: 애플리케이션 모니터링 서비스
• D: 모바일 장치 관리 솔루션

ARM 템플릿 예시:

{
  "type": "Microsoft.Compute/virtualMachineScaleSets/extensions",
  "properties": {
    "publisher": "Microsoft.Compute",
    "type": "CustomScriptExtension",
    "settings": {
      "commandToExecute": "powershell.exe Install-NGINX.ps1"
    }
  }
}

📚 해설

Box 1: "Microsoft.Compute/VirtualMachines/extensions"

• VM 확장을 정의하는 ARM 리소스 유형입니다.
• 도메인 가입 확장을 VM에 추가하는 데 사용됩니다.

Box 2: "ProtectedSettings"

• 민감한 정보(비밀번호 등)를 안전하게 전달하는 섹션입니다.
• 도메인 가입에 필요한 계정 비밀번호를 포함합니다.
• 암호화되어 저장되고 전송됩니다.

도메인 가입 확장 구성:

{
  "type": "Microsoft.Compute/virtualMachines/extensions",
  "properties": {
    "publisher": "Microsoft.Compute",
    "type": "JsonADDomainExtension",
    "settings": {
      "Name": "contoso.com",
      "User": "contoso\\admin",
      "Restart": "true"
    },
    "protectedSettings": {
      "Password": "AdminPassword123"
    }
  }
}

보안 고려사항:

• 비밀번호는 반드시 protectedSettings에 배치
• Key Vault 참조를 통한 보안 강화 권장
• 최소 권한 원칙에 따른 도메인 계정 사용

📚 해설

왜 B가 정답인가:

• 가용성 집합 내에서 VM 크기를 변경하려면 VM을 할당 해제해야 합니다.
• 할당 해제하면 VM이 다른 물리적 호스트로 이동할 수 있어 더 많은 크기 옵션이 제공됩니다.
• VM이 실행 중일 때는 현재 호스트에서 지원하는 크기로만 제한됩니다.

가용성 집합 VM 크기 조정 과정:

1. VM 할당 해제: Stop-AzVM -Deallocate
2. VM 크기 변경: 사용 가능한 크기 중 선택
3. VM 시작: 새로운 크기로 부팅

다른 옵션이 틀린 이유:

• A: 근접 배치 그룹은 크기 제한과 관련 없음
• C: 관리되는 가용성 집합 변환은 크기 문제 해결과 무관
• D: 다른 VM 종료는 필요 없음

가용성 집합 특징:

• 동일한 하드웨어 클러스터 내 배치
• 장애 도메인과 업데이트 도메인으로 분산
• 하드웨어 제약으로 인한 크기 제한 존재

📚 해설

자동 스케일링 규칙 분석:

첫 번째 질문: 최대 인스턴스 수

• 스케일 셋의 최대 인스턴스 제한에 따라 결정됩니다.
• 자동 스케일링 규칙의 최대값이 적용됩니다.

두 번째 질문: 최소 인스턴스 수

• 스케일 인 조건이 충족되어도 최소 인스턴스 수는 유지됩니다.
• 스케일 셋의 최소 인스턴스 설정이 적용됩니다.

자동 스케일링 고려 사항:

• 쿨다운 시간: 스케일링 작업 간 대기 시간
• 메트릭 임계값: CPU, 메모리 등의 조건
• 인스턴스 제한: 최소/최대 인스턴스 수

📚 해설

왜 A가 정답인가:

• App Service 계획의 운영 체제는 지역별로 제한되지 않습니다.
• Linux와 Windows App Service 계획은 모든 Azure 지역에서 지원됩니다.
• 기존 Windows App Service 계획이 있는 지역에 Linux App Service 계획도 생성할 수 있습니다.

App Service 계획 운영 체제:

• 동일 리소스 그룹 내: Windows와 Linux 계획 혼재 가능
• 동일 App Service 계획 내: 하나의 운영 체제만 가능
• 지역 지원: 모든 주요 Azure 지역에서 Linux 지원

고려 사항:

• 리소스 그룹당 운영 체제 제한 없음
• 가격 계층에 따른 기능 차이 존재
• Linux 계획은 컨테이너 기반 앱 지원

📚 해설

왜 B가 정답인가:

• DSC 확장은 VM에 소프트웨어를 설치하고 구성하는 표준 방법입니다.
• 가상 머신 스케일 셋의 모든 인스턴스에 일관되게 NGINX를 설치할 수 있습니다.
• ARM 템플릿에서 DSC 확장을 정의하여 자동화할 수 있습니다.

DSC 확장 장점:

• 선언적 구성: 원하는 상태를 정의
• 일관성: 모든 인스턴스에 동일한 구성 적용
• 자동 복구: 구성이 변경되면 자동으로 복원
• 템플릿 통합: ARM 템플릿에서 직접 정의 가능

다른 옵션이 틀린 이유:

• A: Azure Policy 구성용 cmdlet
• C: 온프레미스 애플리케이션 접근용 프록시
• D: 애플리케이션 성능 모니터링 서비스

📚 해설

ARM 템플릿 배포 명령어:

첫 번째 선택: New-AzResourceGroupDeployment

• 리소스 그룹 수준에서 ARM 템플릿을 배포하는 PowerShell cmdlet입니다.
• VM과 같은 리소스는 일반적으로 리소스 그룹 수준에서 배포됩니다.

두 번째 선택: -ResourceGroupName

• 배포할 대상 리소스 그룹을 지정하는 매개변수입니다.
• 표에서 제공된 RG1을 리소스 그룹으로 사용해야 합니다.

세 번째 선택: -TemplateFile

• 배포할 ARM 템플릿 파일의 경로를 지정합니다.
• 로컬 파일이나 URI를 지정할 수 있습니다.

전체 명령어 예시:

New-AzResourceGroupDeployment -ResourceGroupName RG1 -TemplateFile template.json

📚 해설

왜 B가 정답인가:

• az aks 명령어는 AKS 클러스터 자체를 관리하는 명령어입니다.
• YAML 파일을 Kubernetes 클러스터에 배포하려면 kubectl 명령어를 사용해야 합니다.
• az aks는 클러스터 생성, 업그레이드, 삭제 등의 관리 작업에 사용됩니다.

올바른 명령어:

• kubectl apply -f your-file.yaml - YAML 파일 배포
• kubectl create -f your-file.yaml - 새 리소스 생성
• kubectl get credentials - 클러스터 자격 증명 가져오기

az aks vs kubectl:

• az aks: AKS 클러스터 관리 (Azure 수준)
• kubectl: Kubernetes 리소스 관리 (클러스터 내부)

배포 과정:

1. az aks get-credentials - 클러스터 연결
2. kubectl apply -f deployment.yaml - YAML 배포

📚 해설

왜 B가 정답인가:

• VM 확장으로 Microsoft Monitoring Agent를 추가하는 것은 올바르지만 추가 구성이 필요합니다.
• 데이터 설정 구성만으로는 충분하지 않으며, Agent 구성 설정도 필요합니다.
• Windows 이벤트 로그 수집을 명시적으로 활성화해야 합니다.

올바른 솔루션:

1. Log Analytics 작업 영역 생성
2. Agent 구성: Windows 이벤트 로그 수집 설정
3. MMA 설치: VM에 직접 설치 또는 VM 확장 사용
4. 데이터 소스 구성: 시스템 이벤트 로그 활성화
5. 알림 규칙 생성

누락된 부분:

• Windows 이벤트 로그 데이터 소스 활성화
• 시스템 이벤트 로그 특정 구성
• 오류 레벨 이벤트 필터링 설정

📚 해설

왜 A가 정답인가:

• 모든 필수 구성 요소가 포함되어 있습니다.
• Log Analytics 작업 영역과 데이터 설정 구성으로 이벤트 로그 수집이 가능합니다.
• Microsoft Monitoring Agent가 VM에 직접 설치되어 안정적인 데이터 전송을 보장합니다.
• Azure Monitor 알림이 Log Analytics를 소스로 사용하여 정확한 모니터링이 가능합니다.

완전한 솔루션 구성:

1. Log Analytics 작업 영역: 이벤트 데이터 저장소
2. 데이터 설정 구성: Windows 이벤트 로그 수집 활성화
3. MMA 직접 설치: VM에 안정적인 에이전트 설치
4. 알림 규칙: 조건 기반 알림 생성

알림 쿼리 예시:

Event
| where EventLevelName == "Error" 
| where TimeGenerated > ago(1h)
| where EventLog == "System"
| summarize count() by Computer
| where count_ > 2

📚 해설

왜 B가 정답인가:

• Azure Recovery Services Agent(MARS)는 백업 데이터를 복원하는 데 필요한 에이전트입니다.
• 복원 대상 VM(VM2)에 MARS 에이전트가 설치되어야 합니다.
• 같은 Recovery Services 자격 증명 모음에 등록되어야 백업 데이터에 접근할 수 있습니다.

MARS 에이전트 복원 과정:

1. VM2에 MARS 에이전트 설치
2. 자격 증명 모음에 VM2 등록
3. 백업 항목에서 복원 지점 선택
4. VM2의 원하는 위치로 복원

다른 옵션이 틀린 이유:

• A, D: Windows Server Backup은 로컬 백업용이며 Azure 백업과 관련 없음
• C: VM1에는 이미 MARS 에이전트가 설치되어 있음

참고: VM1에서 폴더 수준 백업이 수행된 것으로 보아 MARS 에이전트를 사용한 백업입니다.

📚 해설

ARM 템플릿 데이터 디스크 구성:

첫 번째 박스: dataDisks

• VM의 storageProfile 섹션에서 데이터 디스크를 정의하는 속성입니다.
• osDisk와 구별되는 추가 저장소 디스크를 정의합니다.

두 번째 박스: lun

• Logical Unit Number의 약자로 각 데이터 디스크의 고유 식별자입니다.
• 0부터 시작하여 순차적으로 할당됩니다.
• VM 내에서 디스크를 식별하는 데 사용됩니다.

세 번째 박스: createOption

• 디스크 생성 방법을 지정하는 속성입니다.
• 일반적인 값: "Empty", "FromImage", "Attach"
• 새 데이터 디스크의 경우 "Empty"를 사용합니다.

데이터 디스크 배열 예시:

"dataDisks": [
  {
    "lun": 0,
    "createOption": "Empty",
    "diskSizeGB": 128
  },
  {
    "lun": 1,
    "createOption": "Empty", 
    "diskSizeGB": 256
  }
]

📚 해설

왜 A가 정답인가:

• VM1이 West US 지역에 있으므로 NIC2도 같은 지역에 생성되어야 합니다.
• 리소스 그룹(RG1)은 네트워크 인터페이스를 생성할 수 있는 유효한 위치입니다.
• VM과 동일한 지역에 있으면 네트워크 인터페이스를 VM에 연결할 수 있습니다.

네트워크 인터페이스 요구사항:

• 지역 일치: VM과 동일한 Azure 지역
• 가상 네트워크: 동일한 VNet 또는 피어링된 VNet
• 구독: 동일한 구독 내

네트워크 인터페이스 생성 후:

1. VM 중지
2. NIC2를 VM에 연결
3. 네트워크 설정 구성
4. VM 시작

다중 NIC 활용:

• 프론트엔드/백엔드 네트워크 분리
• 관리 네트워크 분리
• 고가용성 구성

📚 해설

왜 B가 정답인가:

• VM1이 West US에 있는데 NIC2를 Central US에 생성하려고 합니다.
• 네트워크 인터페이스는 VM과 동일한 Azure 지역에 있어야 합니다.
• 지역이 다르면 NIC를 VM에 연결할 수 없습니다.

Azure 지역 제약사항:

• VM과 NIC: 반드시 동일한 지역
• VNet과 NIC: 동일한 지역 내 VNet에 연결
• 크로스 리전: 직접 연결 불가능

리소스 그룹 vs 지역:

• 리소스 그룹(RG2)은 다른 그룹이어도 상관없음
• 하지만 지역(Central US vs West US)은 일치해야 함
• 리소스 그룹은 논리적 컨테이너일 뿐

📚 해설

왜 A가 정답인가:

• VM1과 NIC2가 모두 West US 지역에 있으므로 연결이 가능합니다.
• 다른 리소스 그룹(RG2)에 있어도 같은 구독 내이므로 문제없습니다.
• 지역이 일치하는 것이 가장 중요한 요구사항입니다.

리소스 그룹 독립성:

• 리소스 그룹은 관리 및 청구 단위일 뿐
• 다른 RG의 리소스 간 연결 가능
• 동일 구독 내에서는 자유로운 참조 가능

📚 해설

왜 D가 정답인가:

• 템플릿이 리소스 그룹을 생성하므로 구독 수준 배포가 필요합니다.
• New-AzDeployment는 구독 수준에서 ARM 템플릿을 배포하는 cmdlet입니다.
• 리소스 그룹 자체를 생성하는 템플릿은 구독 범위에서 실행되어야 합니다.

ARM 배포 범위별 cmdlet:

• 구독 수준: New-AzDeployment
• 리소스 그룹 수준: New-AzResourceGroupDeployment
• 관리 그룹 수준: New-AzManagementGroupDeployment
• 테넌트 수준: New-AzTenantDeployment

다른 옵션이 틀린 이유:

• A: 단일 리소스 생성용
• B: 기존 리소스 그룹 내 배포용
• C: 테넌트 전체 배포용

템플릿 특징:

• targetScope가 "subscription"으로 설정됨
• 리소스 그룹 생성 후 Storage 계정 생성

📚 해설

Box 1: Azure Storage 계정

• App Service 백업은 Azure Storage 계정을 대상으로 합니다.
• 백업 데이터는 Storage 계정의 컨테이너에 저장됩니다.
• 앱과 동일한 구독의 Storage 계정이어야 합니다.

Box 2: _backup.filter 파일

• 백업에서 파일과 폴더를 제외하는 데 사용되는 특수 파일입니다.
• D:\home\site\wwwroot 폴더에 생성해야 합니다.
• 제외할 파일과 폴더 목록을 이 파일에 지정합니다.

App Service 백업 구성 요소:

• 앱 구성: 설정 및 연결 문자열
• 파일 콘텐츠: 웹앱 파일 시스템
• 연결된 데이터베이스: SQL Database 등

_backup.filter 파일 예시:

\Folder2\
\logs\*.log
\temp\*

📚 해설

왜 C가 정답인가:

• Custom Script Extension은 VM 배포 후 스크립트를 실행하는 표준 방법입니다.
• NGINX 설치와 같은 소프트웨어 설치 작업에 적합합니다.
• ARM 템플릿에서 직접 정의하여 자동화할 수 있습니다.
• 가상 머신 스케일 셋의 모든 인스턴스에 동일하게 적용됩니다.

Custom Script Extension 장점:

• 유연성: PowerShell, Bash 스크립트 실행 가능
• 자동화: VM 생성과 동시에 실행
• 확장성: 스케일 셋의 모든 인스턴스에 적용
• 통합성: ARM 템플릿에 포함 가능

다른 옵션이 틀린 이유:

• A: DSC 구성 게시용 cmdlet이지 직접 설치용이 아님
• B: 애플리케이션 모니터링 서비스
• D: 모바일 장치 관리 솔루션

ARM 템플릿 예시:

{
  "type": "Microsoft.Compute/virtualMachineScaleSets/extensions",
  "properties": {
    "publisher": "Microsoft.Compute",
    "type": "CustomScriptExtension",
    "settings": {
      "commandToExecute": "powershell.exe Install-NGINX.ps1"
    }
  }
}

📚 해설

Box 1: "Microsoft.Compute/VirtualMachines/extensions"

• VM 확장을 정의하는 ARM 리소스 유형입니다.
• 도메인 가입 확장을 VM에 추가하는 데 사용됩니다.

Box 2: "ProtectedSettings"

• 민감한 정보(비밀번호 등)를 안전하게 전달하는 섹션입니다.
• 도메인 가입에 필요한 계정 비밀번호를 포함합니다.
• 암호화되어 저장되고 전송됩니다.

도메인 가입 확장 구성:

{
  "type": "Microsoft.Compute/virtualMachines/extensions",
  "properties": {
    "publisher": "Microsoft.Compute",
    "type": "JsonADDomainExtension",
    "settings": {
      "Name": "contoso.com",
      "User": "contoso\\admin",
      "Restart": "true"
    },
    "protectedSettings": {
      "Password": "AdminPassword123"
    }
  }
}

보안 고려사항:

• 비밀번호는 반드시 protectedSettings에 배치
• Key Vault 참조를 통한 보안 강화 권장
• 최소 권한 원칙에 따른 도메인 계정 사용

📚 해설

왜 B가 정답인가:

• 가용성 집합 내에서 VM 크기를 변경하려면 VM을 할당 해제해야 합니다.
• 할당 해제하면 VM이 다른 물리적 호스트로 이동할 수 있어 더 많은 크기 옵션이 제공됩니다.
• VM이 실행 중일 때는 현재 호스트에서 지원하는 크기로만 제한됩니다.

가용성 집합 VM 크기 조정 과정:

1. VM 할당 해제: Stop-AzVM -Deallocate
2. VM 크기 변경: 사용 가능한 크기 중 선택
3. VM 시작: 새로운 크기로 부팅

다른 옵션이 틀린 이유:

• A: 근접 배치 그룹은 크기 제한과 관련 없음
• C: 관리되는 가용성 집합 변환은 크기 문제 해결과 무관
• D: 다른 VM 종료는 필요 없음

가용성 집합 특징:

• 동일한 하드웨어 클러스터 내 배치
• 장애 도메인과 업데이트 도메인으로 분산
• 하드웨어 제약으로 인한 크기 제한 존재

📚 해설

AKS 클러스터 구성 분석:

첫 번째 질문: 노드 수

• 클러스터 생성 시 설정된 초기 노드 수가 적용됩니다.
• 자동 스케일링이 활성화된 경우 최소/최대 범위 내에서 조정됩니다.
• 이미지에서 설정된 노드 수를 확인할 수 있습니다.

두 번째 질문: 네트워크 모델

• Kubenet: 기본 네트워킹, 단순한 설정
• Azure CNI: 고급 네트워킹, VNet 통합
• 선택된 네트워킹 옵션에 따라 결정됩니다.

AKS 네트워킹 옵션:

• Kubenet: 노드는 VNet 서브넷 IP, 파드는 별도 주소 공간
• Azure CNI: 노드와 파드 모두 VNet IP 사용

클러스터 생성 시 고려사항:

• 노드 수: 초기 워크로드에 적합한 수 선택
• 자동 스케일링: 트래픽 변화에 대응
• 네트워킹: 기존 인프라와의 통합 고려
• 노드 풀: 다양한 워크로드 유형 지원

📚 해설

AKS 클러스터 업그레이드 명령어:

첫 번째 선택: az aks upgrade

• AKS 클러스터를 업그레이드하는 Azure CLI 명령어입니다.
• Kubernetes 버전을 최신 버전으로 업데이트합니다.

두 번째 선택: --max-surge

• 업그레이드 중 추가로 생성할 노드 수를 지정합니다.
• 값 2는 2개의 추가 노드를 생성하여 롤링 업그레이드를 수행합니다.
• 비용 최소화를 위해 필요한 최소 개수만 지정합니다.

업그레이드 과정:

1. 서지 노드 생성: 2개의 새 노드 추가
2. 워크로드 이동: 기존 노드에서 새 노드로 파드 이동
3. 기존 노드 업그레이드: 순차적으로 업그레이드
4. 서지 노드 제거: 업그레이드 완료 후 추가 노드 삭제

비용 최적화:

• max-surge 값을 최소화하여 추가 노드 수 제한
• 업그레이드 시간과 비용 간의 균형 고려

📚 해설

ARM 템플릿 배포 분석:

첫 번째 문장: 예

• 템플릿이 성공적으로 배포됩니다.
• 구독 수준 배포 명령어가 올바르게 사용되었습니다.
• 템플릿 구문이 유효합니다.

두 번째 문장: 아니오

• 템플릿에서 리소스 그룹이 생성됩니다.
• 구독 수준에서 배포되므로 새 리소스 그룹이 만들어집니다.

세 번째 문장: 예

• 템플릿에 Storage 계정 리소스가 정의되어 있습니다.
• 생성된 리소스 그룹 내에 Storage 계정이 배포됩니다.

배포 결과:

• 새 리소스 그룹 생성
• 리소스 그룹 내 Storage 계정 생성
• 구독 수준 리소스로 관리

📚 해설

왜 A가 정답인가:

• Azure Container Instances가 Private 레지스트리에서 이미지를 가져오려면 인증이 필요합니다.
• 관리 사용자를 활성화하면 사용자 이름과 비밀번호 기반 인증이 가능해집니다.
• ACI가 ACR에서 이미지를 성공적으로 풀할 수 있게 됩니다.

ACR 인증 방법:

• 관리 사용자: 사용자 이름/비밀번호 인증
• 서비스 주체: Azure AD 기반 인증
• 관리 ID: Azure 리소스의 관리 ID 사용
• Azure AD 토큰: 개별 사용자 인증

관리 사용자 활성화 후:

1. ACR에서 사용자 이름과 비밀번호 생성
2. ACI 배포 시 이미지 레지스트리 자격 증명 제공
3. 성공적인 이미지 풀 및 컨테이너 배포

보안 고려사항:

• 프로덕션 환경에서는 서비스 주체 사용 권장
• 관리 사용자는 개발/테스트 환경에 적합

📚 해설

ARM 템플릿 배포 모드:

첫 번째 선택: New-AzResourceGroupDeployment

• 리소스 그룹 수준에서 ARM 템플릿을 배포하는 PowerShell cmdlet입니다.
• 기존 리소스 그룹에 리소스를 배포할 때 사용됩니다.

두 번째 선택: Complete

• 배포 모드를 "Complete"로 설정하면 기존 리소스를 모두 제거합니다.
• 템플릿에 정의되지 않은 모든 리소스는 삭제됩니다.
• 템플릿에 정의된 리소스만 리소스 그룹에 남게 됩니다.

배포 모드 비교:

• Incremental (기본값): 기존 리소스를 유지하고 새 리소스만 추가
• Complete: 템플릿에 정의되지 않은 기존 리소스는 모두 삭제

Complete 모드 주의사항:

• 리소스 그룹의 모든 기존 리소스가 삭제될 수 있음
• 신중하게 사용해야 하는 강력한 기능
• 백업 및 복구 계획 수립 필요

📚 해설

App Service 자동 스케일링 분석:

첫 번째 질문: 스케일 아웃 시나리오

• CPU 사용률이 임계값을 초과하면 인스턴스가 추가됩니다.
• 지속 시간과 쿨다운 시간에 따라 스케일링이 조정됩니다.
• 최대 인스턴스 제한까지 확장 가능합니다.

두 번째 질문: 스케일 인 시나리오

• CPU 사용률이 임계값 아래로 떨어지면 인스턴스가 제거됩니다.
• 최소 인스턴스 수는 항상 유지됩니다.
• 쿨다운 시간이 적용되어 급격한 변화를 방지합니다.

자동 스케일링 고려사항:

• 메트릭: CPU, 메모리, 요청 수 등
• 임계값: 스케일 작업을 트리거하는 값
• 지속 시간: 임계값 유지 시간
• 쿨다운: 연속 스케일링 방지 시간

📚 해설

왜 D가 정답인가:

• 컨테이너 그룹의 모든 컨테이너는 동일한 운영 체제 유형이어야 합니다.
• Instance1과 Instance2는 Windows 컨테이너이고, Instance3과 Instance4는 Linux 컨테이너입니다.
• Windows와 Linux 컨테이너를 같은 컨테이너 그룹에 배치할 수 없습니다.

Azure Container Groups 제약사항:

• 운영 체제: 그룹 내 모든 컨테이너는 동일한 OS
• 지역: 모든 컨테이너는 동일한 Azure 지역
• 네트워킹: 그룹 내 컨테이너는 IP와 포트 공유
• 스토리지: 그룹 내 컨테이너는 볼륨 공유 가능

컨테이너 그룹 장점:

• 사이드카 패턴 구현
• 리소스 공유 및 통신
• 동일한 생명주기 관리
• 로컬 네트워크 통신

표에서 분석:

• Instance1, Instance2: Windows - 별도 그룹 필요
• Instance3, Instance4: Linux - 같은 그룹 가능

📚 해설

Azure Container Registry 전용 데이터 엔드포인트:

첫 번째 설정: Premium SKU

• 전용 데이터 엔드포인트는 Premium SKU에서만 지원됩니다.
• Basic이나 Standard SKU는 이 기능을 지원하지 않습니다.
• SKU를 Premium으로 업그레이드해야 합니다.

두 번째 설정: 전용 데이터 엔드포인트 활성화

• Premium SKU로 업그레이드 후 전용 데이터 엔드포인트를 명시적으로 활성화해야 합니다.
• 네트워킹 섹션에서 설정을 변경할 수 있습니다.
• 지역별로 별도의 데이터 엔드포인트가 생성됩니다.

전용 데이터 엔드포인트 장점:

• 성능 향상: 지역별 최적화된 데이터 전송
• 네트워크 최적화: 트래픽 라우팅 개선
• 보안 강화: 프라이빗 엔드포인트와 함께 사용 가능
• 대역폭 절약: 지역 내 데이터 전송

설정 순서:

1. ACR SKU를 Premium으로 업그레이드
2. 네트워킹 설정에서 전용 데이터 엔드포인트 활성화
3. 필요한 지역별 엔드포인트 구성

📚 해설

왜 B가 정답인가:

• Azure Firewall은 Standard SKU 공용 IP 주소만 지원합니다.
• Basic SKU 공용 IP는 Azure Firewall과 호환되지 않습니다.
• 표에서 IP1과 IP2만 Standard SKU입니다.
• IPv6 주소는 Azure Firewall에서 지원되지 않습니다.

Azure Firewall IP 요구사항:

• SKU: Standard 공용 IP만 지원
• 할당: 정적 할당 필요
• 버전: IPv4 지원 (IPv6는 미지원)
• 지역: Firewall과 동일한 지역

Azure Firewall Premium 기능:

• TLS 검사: 암호화된 트래픽 검사
• IDPS: 침입 탐지 및 방지 시스템
• URL 필터링: 웹 카테고리 기반 필터링
• 웹 카테고리: 사이트 분류 및 차단

IP 주소 사용 패턴:

• 관리 IP: 방화벽 관리 트래픽용
• 데이터 IP: 사용자 데이터 트래픽용
• 고가용성: 추가 IP로 이중화 구성
• SNAT 포트: 아웃바운드 연결 확장

표 분석:

• IP1, IP2: Standard SKU ✓
• IP3, IP4, IP5: Basic SKU 또는 IPv6 ✗

📚 해설

ARM 템플릿 VM 리소스 구성:

첫 번째 박스: Microsoft.Compute/virtualMachines

• Azure 가상 머신을 정의하는 ARM 리소스 유형입니다.
• 가상 머신의 모든 구성을 포함합니다.

두 번째 박스: networkProfile

• VM의 네트워크 구성을 정의하는 섹션입니다.
• 네트워크 인터페이스 연결 정보를 포함합니다.

세 번째 박스: networkInterfaces

• VM에 연결된 네트워크 인터페이스를 참조하는 배열입니다.
• 하나 이상의 NIC를 VM에 연결할 수 있습니다.

VM ARM 템플릿 주요 섹션:

• hardwareProfile: VM 크기 정의
• storageProfile: OS 디스크 및 데이터 디스크
• osProfile: 운영체제 및 인증 정보
• networkProfile: 네트워크 인터페이스

📚 해설

가격 계획: Standard

• 사용자 지정 도메인 지원을 위해서는 최소 Basic 계층 필요
• 자동 스케일링 기능은 Standard 계층부터 지원
• 최대 8개 인스턴스 확장이 가능
• 비용 최소화를 위해 Standard 계층 선택

도메인 확인 레코드: TXT

• TXT 레코드는 도메인 소유권을 안전하게 확인하는 표준 방법
• Azure에서 제공하는 확인 문자열을 TXT 레코드에 추가
• CNAME보다 더 안전하고 표준적인 방법

App Service 가격 계층 비교:

• Free/Shared: 사용자 지정 도메인 미지원
• Basic: 사용자 지정 도메인 지원, 자동 스케일링 미지원
• Standard: 사용자 지정 도메인, 자동 스케일링 지원
• Premium: 고급 기능, 더 높은 성능

도메인 확인 과정:

1. Azure에서 확인 문자열 생성
2. DNS에 TXT 레코드 추가
3. Azure에서 소유권 확인
4. 사용자 지정 도메인 바인딩

📚 해설

Azure Compute Gallery 호환성 분석:

첫 번째 문장: 예

• VM1은 Windows Server 2019를 실행하고 이미지 정의도 Windows Server 2019용입니다.
• 운영체제가 일치하므로 VM1에서 이미지 버전을 생성할 수 있습니다.

두 번째 문장: 아니오

• VM2는 Ubuntu 18.04를 실행하지만 이미지 정의는 Windows Server 2019용입니다.
• 운영체제가 다르므로 VM2에서는 이미지 버전을 생성할 수 없습니다.

세 번째 문장: 아니오

• VM3는 Windows Server 2016을 실행하지만 이미지 정의는 Windows Server 2019용입니다.
• Windows 버전이 다르므로 VM3에서는 이미지 버전을 생성할 수 없습니다.

Azure Compute Gallery 요구사항:

• 운영체제 일치: 소스 VM과 이미지 정의의 OS가 동일해야 함
• 버전 일치: 정확한 OS 버전까지 일치해야 함
• 아키텍처 일치: x64, ARM 등 아키텍처가 동일해야 함

📚 해설

왜 B가 정답인가:

• App Service 계획은 운영체제별로 분리되어야 합니다.
• 하나의 App Service 계획에는 Windows 또는 Linux 앱만 호스팅할 수 있습니다.
• 표에서 Windows와 Linux 앱이 혼재되어 있으므로 최소 2개의 계획이 필요합니다.

App Service 계획 분리 기준:

• 운영체제: Windows vs Linux (혼재 불가)
• 지역: 동일한 Azure 지역 내에서만 공유 가능
• 리소스 그룹: 다른 리소스 그룹의 앱도 공유 가능

효율적인 계획 구성:

• 계획 1: 모든 Windows 웹앱
• 계획 2: 모든 Linux 웹앱

비용 최적화:

• 동일한 운영체제의 여러 앱을 하나의 계획에 배치
• 리소스 공유로 비용 절감
• 필요에 따라 스케일링 조정

표 분석 예시:

• Windows 앱들 → App Service Plan 1
• Linux 앱들 → App Service Plan 2

📚 해설

ARM 템플릿 배포 결과 분석:

첫 번째 문장: 아니오

• 템플릿 배포 자체는 성공하지만 Storage 계정 생성은 실패합니다.
• 네트워크 보안 그룹 생성은 성공할 수 있습니다.

두 번째 문장: 예

• Storage 계정 이름은 전역적으로 고유해야 합니다.
• 템플릿의 Storage 계정 이름이 이미 사용 중이면 배포가 실패합니다.
• 이름 충돌로 인한 오류가 발생합니다.

세 번째 문장: 예

• 네트워크 보안 그룹은 리소스 그룹 내에서만 고유하면 됩니다.
• Storage 계정과 달리 전역 고유성이 필요하지 않습니다.
• NSG는 성공적으로 생성될 가능성이 높습니다.

Azure 리소스 이름 지정 규칙:

• 전역 고유: Storage 계정, Azure AD 테넌트
• 리소스 그룹 내 고유: VM, NSG, VNet
• 구독 내 고유: 리소스 그룹

📚 해설

왜 D가 정답인가:

• 메모리 사용률이 80%로 스케일 아웃 임계값을 초과합니다.
• 30분은 충분히 긴 시간으로 여러 번의 스케일 아웃이 가능합니다.
• 최대 인스턴스 제한이 5로 설정되어 있으므로 5개까지 확장됩니다.
• 스케일 아웃 조건이 지속적으로 충족되므로 최대치까지 확장됩니다.

자동 스케일링 동작:

1. 초기 상태: 2개 인스턴스
2. 첫 번째 스케일 아웃: 조건 충족 시 인스턴스 추가
3. 쿨다운 대기: 설정된 쿨다운 시간 경과
4. 추가 스케일 아웃: 조건이 계속 충족되면 반복
5. 최대 도달: 5개 인스턴스까지 확장

스케일링 고려사항:

• 지속 시간: 임계값을 넘는 시간
• 쿨다운: 연속 스케일링 간 대기 시간
• 증가 단위: 한 번에 추가되는 인스턴스 수
• 최대 제한: 설정된 최대 인스턴스 수

30분 시나리오:

• 충분한 시간으로 여러 차례 스케일 아웃 실행
• 메모리 사용률 80% 지속으로 조건 계속 충족
• 최대 제한인 5개 인스턴스까지 도달

📚 해설

Azure 컨테이너 서비스 호환성:

Azure Container Instances (ACI):

• Linux와 Windows 컨테이너 모두 지원
정답 및 해설 보기
정답

📚 해설
AKS 클러스터 구성 분석:
첫 번째 질문: 노드 수
• 클러스터 생성 시 설정된 초기 노드 수가 적용됩니다.
• 자동 스케일링이 활성화된 경우 최소/최대 범위 내에서 조정됩니다.
두 번째 질문: 네트워크 모델
• Kubenet: 기본 네트워킹, 단순한 설정
• Azure CNI: 고급 네트워킹, VNet 통합
AKS 네트워킹 옵션:
• Kubenet: 노드는 VNet 서브넷 IP, 파드는 별도 주소 공간
• Azure CNI: 노드와 파드 모두 VNet IP 사용