Microsoft AZ-400: 컨테이너화 및 Kubernetes — 학습 가이드

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

다음의 일부입니다: Microsoft DevOps Engineer Expert AZ-400 — 학습 가이드. 검증된 답안으로 연습하기: Microsoft 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

개요

컨테이너화와 Kubernetes는 재현 가능한 빌드, 안전한 배포, 선언적이고 자가 치유(self-healing)가 가능한 런타임 오케스트레이션을 결합하여 Azure에서의 최신 DevOps를 뒷받침합니다. 이를 마스터하려면 이미지를 구성하고 최적화하는 방법, 레지스트리가 콘텐츠를 복제하고 증명하는 방법, AKS를 중단 없이 설계하고 업그레이드하는 방법, 점진적 배포(progressive delivery)를 구현하는 방법, 워크로드를 엔드투엔드로 보호하는 방법을 이해해야 합니다. 순수 Kubernetes를 넘어, 패키징을 위해 Helm을, 조정(reconciliation)을 위해 GitOps를 활용하고, 서버리스 영역에서는 Dapr 및 KEDA와 함께 Azure Container Apps를 사용하여 마이크로서비스 패턴과 이벤트 기반 스케일링을 단순화하게 됩니다. 다음 섹션에서는 견고하고 규정을 준수하는 파이프라인과 복원력 있는 프로덕션 클러스터를 구현하는 데 필요한 플랫폼 결정 및 운영 관행의 핵심을 설명합니다.

빌드 및 레지스트리 기본 사항: Docker와 ACR

성능이 뛰어난 컨테이너 이미지는 결정론적인(deterministic) Dockerfile과 잘 관리된 빌드 컨텍스트에서 시작됩니다. 다단계 빌드(Multi-stage build)를 사용하면 툴체인이 무거운 컴파일 단계를 작은 런타임 이미지와 분리할 수 있습니다. 예를 들어, 빌더 단계에서 .NET 또는 Go 바이너리를 컴파일한 다음, 컴파일된 아티팩트만 distroless 또는 최소 기본 이미지(예: mcr.microsoft.com/dotnet/runtime-deps 또는 gcr.io/distroless/base)로 복사하면 공격 표면이 줄어들고 풀(pull) 시간이 단축됩니다. 모든 RUN, COPY, ADD는 레이어를 생성합니다. 자주 변경되지 않는 단계를 뒤에 배치하고, 가독성을 유지하면서 논리적 그룹화로 명령을 집계하여 Dockerfile을 재구성하면 레이어 캐시 히트율을 극대화할 수 있습니다. 항상 .dockerignore 파일을 포함하여 bin/obj, node_modules, 테스트, 문서, 보안 비밀 등을 제외하십시오. 빌드 컨텍스트가 너무 크면 업로드 속도가 느려지고 원격 캐시 효율성이 감소합니다. 결정론적인 패키지 설치(버전 고정, 잠금 파일)와 빌드 인수를 신중하게 사용하십시오. 환경별 파일은 불변의 이미지가 아닌 런타임 구성을 통해 전달되어야 합니다.

Azure Container Registry (ACR)는 이미지 저장 및 배포의 중추입니다. ACR Tasks를 활용하여 빌드를 Azure로 오프로드하십시오. 주문형 빌드를 위한 빠른 작업(az acr run), Git 커밋, 기본 이미지 업데이트 또는 일정에 따라 트리거되는 자동화된 작업, 그리고 Buildx를 사용하는 다중 아키텍처(multi-arch) 이미지를 위한 다단계 Task YAML이 있습니다. 지역 복제(Geo-replication, Premium SKU)는 여러 리전에 걸쳐 아티팩트를 미러링하여 다중 리전 AKS/ACA 배포의 풀 지연 시간과 이그레스(egress) 비용을 최소화합니다. 이를 프라이빗 엔드포인트 및 리포지토리 범위의 RBAC와 결합하여 최소 권한 원칙을 적용하십시오. 콘텐츠 신뢰(content trust)를 활성화하여 이미지를 서명하고 출처를 확인하십시오. Docker Content Trust/Notary 및 진화하는 OCI 서명 생태계(예: cosign)는 보호된 네임스페이스에 서명을 요구하는 OPA Gatekeeper 제약 조건을 통해 어드미션(admission) 시에 강제할 수 있습니다. 취약점 검사를 통합하십시오. Microsoft Defender for Cloud는 푸시 시점과 저장된 이미지(at rest)를 검사하고, 수정 가이드와 함께 CVE를 표시하며, Azure Policy 및 CI 검사를 통해 배포를 차단(gate)할 수 있습니다. 알려진 취약점이 있는 레이어를 줄이기 위해 기본 이미지 새로 고침 자동화를 포함하십시오.

AKS 플랫폼 및 워크로드 제공

기본적으로 보안이 설정된 AKS 클러스터를 생성합니다. 여기에는 관리형 ID, RBAC를 위한 Azure AD 통합, VNET 통합을 위한 Azure CNI, 네트워크 정책(Azure 또는 Calico), 시크릿 사용을 위한 Azure Key Vault 공급자(Secrets Store CSI), 그리고 승인된 IP 범위를 사용하는 프라이빗 클러스터가 포함됩니다. 워크로드에 적합한 노드 풀을 선택합니다. 컨트롤 플레인의 중요 컴포넌트를 위한 시스템 풀, 애플리케이션을 위한 사용자 풀, ML을 위한 GPU 풀, 비용 절감형 상태 비저장 작업을 위한 스팟 풀, Windows 컨테이너를 위한 Windows 노드 풀 등이 있습니다. taints/tolerations와 topology spread constraints를 사용하여 스케줄링과 복원력을 제어합니다. cluster autoscaler와 배포별 Horizontal Pod Autoscaler로 자동 확장하고, 성능과 복원력을 위해 임시 OS 디스크와 가용성 영역 사용을 고려합니다.

중단을 최소화하도록 업그레이드를 계획합니다. AKS는 컨트롤 플레인을 먼저 업그레이드한 다음 노드 풀을 업그레이드합니다. 노드 풀 업그레이드 시 max-surge를 사용하여 서지(surge) 용량을 추가하고, 노드를 정상적으로 드레이닝(drain)하며, PodDisruptionBudgets를 준수합니다. 예측 가능한 주기를 위해 자동 업그레이드 채널(rapid/stable/patch-only)을 채택하고, 시스템 풀과 사용자 풀 업그레이드를 분리하여 영향 반경을 제한합니다. Kubernetes 버전 상승 없이도 커널/런타임 수정을 적용하기 위해 정기적으로 노드 이미지 업그레이드를 수행하고, 호환되는 CNI/CSI 버전을 고정합니다. 무중단 플랫폼 변경을 위해 블루-그린 노드 풀을 사용합니다. 즉, 그린 풀을 cordon/drain하여 블루 풀로 전환하고 nodeSelector/affinity를 통해 전환을 완료합니다.

Kubernetes의 Deployments는 기본적으로 maxUnavailable 및 maxSurge를 사용하는 롤링 업데이트를 지원하여 롤아웃 중 용량을 유지합니다. 조기 트래픽 유입을 방지하기 위해 readiness/liveness 프로브 및 startup 프로브와 함께 사용합니다. Kubernetes에서의 블루-그린 배포는 병렬 Deployments(블루와 그린)를 실행하고 안정적인 Service 셀렉터나 Endpoint 객체를 대상 리비전으로 전환하여 구현합니다. 이를 통해 레이블을 변경하는 것만으로 거의 즉각적인 롤백이 가능합니다. 카나리 배포는 인그레스(ingress)를 통해 엣지에서 수행하는 것이 가장 좋습니다. NGINX Ingress는 어노테이션을 통해 가중치 기반 카나리를 지원하고, Application Gateway Ingress Controller (AGIC)는 백엔드 간에 트래픽을 분할할 수 있으며, 서비스 메시는 세분화된 정책과 텔레메트리를 통해 트래픽 전환을 제공합니다. 견고한 파이프라인을 위해, 가중치를 올리기 전에 스모크 테스트와 App Insights 가용성 검사로 유효성을 검증합니다.

Helm은 Kubernetes 매니페스트를 Chart.yaml, 템플릿, 기본 values.yaml로 구성된 차트(chart)로 패키징합니다. Values 파일은 결정론적으로 계층화됩니다. values.<env>.yaml 오버레이를 사용하고, 하위 차트 간의 설정을 위해 “global” 블록을 사용합니다. ACR에 OCI 기반 차트 스토리지를 사용하는 Helm 3를 선호합니다(helm registry login && helm push oci://…). 이를 통해 이미지와 동등한 RBAC 및 지역 복제 기능을 사용할 수 있습니다. Azure Pipelines에서는 고정된 버전의 Helm을 설치(HelmInstaller)하고 Kubernetes/Azure Resource Manager 서비스 연결을 통해 배포(HelmDeploy)합니다. 템플릿 린팅과 함께 dry-run 및 diff(helm diff plugin)를 사용하여 릴리스를 통제해야 합니다. values 파일에 시크릿을 커밋하지 말고, external-secrets 또는 CSI Key Vault를 통합하여 런타임에 시크릿을 구체화합니다. 차트는 유의적 버전을 사용하고, 추적성을 위해 appVersion을 이미지 다이제스트에 고정합니다.

운영, 보안 및 트래픽 제어

Flux 또는 Argo CD를 사용하는 GitOps는 클러스터가 선언된 상태로 지속적으로 수렴하도록 보장합니다. Flux v2는 Azure CLI/확장을 통해 AKS와 기본적으로 통합되며, 일정 간격으로 Sources(Git/OCI/Bucket)와 Kustomizations를 조정하고, 정책에 따라 Helm/Kustomize를 새 태그로 업데이트하는 이미지 자동화를 포함합니다. Argo CD는 애플리케이션과 그 상태를 추적하고, Azure AD를 통한 SSO를 지원하며, 멀티테넌트 분리를 위해 풀(pull) 기반의 앱-오브-앱스(app-of-apps) 모델로 작동할 수 있습니다. 두 도구 모두 드리프트를 감지하고 자동 수정할 수 있으며, 이벤트/경고를 발생시키고 점진적 배포를 지원합니다. Flagger와 함께 사용하여 NGINX, Istio 또는 Linkerd를 이용한 카나리 및 A/B 테스트를 자동화하고, 메트릭을 기반으로 승격하며 SLO 위반 시 롤백합니다.

보안은 공급망에서 시작하여 어드미션(admission) 및 런타임에 강제됩니다. Defender for Cloud로 이미지를 지속적으로 스캔하고 CI/CD에서 게이트를 표면화합니다. 네임스페이스에 Pod Security Admission 레이블을 사용하여 Kubernetes Pod Security Standards(baseline/restricted)를 채택하고, 기본적으로 privileged/hostPath/unsafe sysctls를 차단합니다. OPA Gatekeeper로 조직 정책을 강제합니다. 제약 조건 템플릿은 권한 있는 컨테이너를 금지하고, 승인된 레지스트리 사용을 요구하며, 리소스 제한을 강제하고, 서명된 이미지나 SBOM 존재를 요구합니다. 네트워크 정책을 적용하여 허용되는 파드 간 및 이그레스(egress) 트래픽을 정의합니다. AKS는 Azure Network Policies(Azure CNI 사용)와 Calico를 지원합니다. Azure Firewall 또는 NVA 이그레스 제어 및 Application Gateway WAF 인그레스로 보완합니다. 루트가 아닌 사용자, 읽기 전용 루트 파일 시스템, seccomp 및 AppArmor 프로필, 정기적인 노드 이미지 업그레이드로 워크로드를 강화합니다. Defender for Kubernetes를 통해 감사 및 위협 탐지를 활성화하고 Azure Monitor Container Insights에서 텔레메트리를 집계합니다. OpenTelemetry로 로그/추적을 표준화합니다.

서비스 메시(Istio 또는 Linkerd)는 일관된 트래픽 관리, 암호화 및 관찰 가능성을 추가합니다. DestinationRules/VirtualServices(Istio) 또는 ServiceProfiles(Linkerd)를 사용하여 재시도, 타임아웃, 서킷 브레이킹, 가중치 기반 라우팅을 정의합니다. 서비스 간 암호화 및 ID를 위해 상호 TLS(mTLS)를 활성화하고, “STRICT” mTLS와 같은 정책을 강제하여 보안 격차를 해소합니다. 메트릭을 Prometheus로, 대시보드를 Grafana로 내보냅니다. 분산 추적(Jaeger/Zipkin)을 캡처하고 OpenTelemetry 수집기를 통해 Application Insights 또는 Azure Monitor로 전송합니다. 메시 기반 카나리 및 결함 주입은 신뢰할 수 있는 테스트와 점진적 배포를 강화하며, Flagger는 SLO에 대한 분석을 자동화합니다.

Azure의 개발자 생산성 및 서버리스 컨테이너

AKS DevOps 통합 도구는 개발 이너 루프(inner loop)를 간소화합니다. Draft는 언어 프레임워크를 감지하고 Dockerfile, Helm 차트, 실행 구성을 스캐폴딩하여 컨테이너화를 가속합니다. Bridge to Kubernetes는 라이브 클러스터의 서비스 호출을 로컬 워크스테이션으로 리디렉션하여, 나머지 서비스는 실제 데이터와 종속성을 가진 클러스터 내에서 실행되는 동안 단일 마이크로서비스를 로컬에서 반복하고 디버깅할 수 있게 해줍니다. Azure Dev Spaces는 더 이상 사용되지 않으며, Bridge to Kubernetes가 지원되는 로컬 개발 환경으로 VS Code 및 Visual Studio와 통합됩니다.

Azure Container Apps(ACA)는 Kubernetes를 관리할 필요 없이 마이크로서비스와 작업을 위한 서버리스 완전 관리형 런타임을 제공합니다. 각 배포는 리비전(revision)을 생성하며, 단일 명령어 또는 YAML 변경으로 블루-그린 또는 카나리 방식의 롤아웃을 위해 리비전 간에 트래픽을 백분율로 라우팅할 수 있습니다. 네이티브 Dapr 통합은 별도의 복잡한 설정 없이 서비스 호출, pub/sub, 바인딩, 상태 저장소, 시크릿 관리를 가능하게 합니다. 플러그형 컴포넌트(예: Azure Service Bus, Key Vault, Cosmos DB)는 일관된 서비스 간 기능 구현을 가속합니다. KEDA는 HTTP 동시성 및 60개 이상의 스케일러(Azure Queue/Service Bus, Kafka, Prometheus, 사용자 지정)를 기반으로 이벤트 기반 자동 스케일링을 지원하며, 비용 효율성을 위해 0으로 스케일링(scale to zero)할 수 있습니다. ACA 환경(Environments)을 사용하여 네트워크 격리 및 VNET 통합을 구현하고, 관리형 ID를 통해 ACR을 연결하며, containerapps YAML을 통해 구성을 관리하여 GitOps 방식과의 선언적 패리티를 유지합니다.

실제 문제 시나리오

Adobe는 다중 리전 고객 분석 서비스를 현대화하여 릴리스 위험을 줄이는 동시에 공급망 및 런타임 보안을 강화해야 합니다. 팀은 빌드를 표준화하고, 안전한 롤아웃을 자동화하며, US 및 EU 전역에 걸쳐 신속하고 규정을 준수하는 배포를 보장해야 합니다.

1. 모든 서비스에 다단계 Dockerfile 및 .dockerignore 구현

• 이유: 이미지 크기와 공격 표면을 최소화하고, 빌드 캐시 히트율을 개선하며, 시크릿이나 대용량 테스트 자산이 이미지에 실수로 포함되는 것을 방지합니다.

2. ACR Tasks로 이미지 빌드 및 서명 후, 지역 복제된 ACR로 푸시

• 이유: 클라우드 빌드는 로컬 환경의 차이를 제거합니다. 기본 이미지 업데이트 트리거는 CVE 노출을 줄입니다. 프리미엄 ACR의 지역 복제 기능은 아티팩트를 AKS 클러스터와 동일한 위치에 배치하여 지연 시간과 이그레스(egress) 비용을 줄입니다. 서명은 출처(provenance)를 보장합니다.

3. Defender for Cloud 이미지 스캔 활성화 및 CI 게이트와 OPA Gatekeeper를 통해 정책 강제

• 이유: 푸시 시점과 저장된 상태(at rest)에서의 스캔으로 CVE를 조기에 발견합니다. Gatekeeper 제약 조건은 “승인된 레지스트리만 사용”, “서명된 이미지만 허용” 및 리소스 제한과 같은 정책을 강제하여 안전하지 않은 워크로드가 어드미션(admission)되는 것을 방지합니다.

4. Azure CNI, 네트워크 정책, 관리형 ID를 사용하여 리전별로 프라이빗 AKS 클러스터 프로비저닝

• 이유: 프라이빗 엔드포인트는 컨트롤 플레인 노출을 제한합니다. Azure CNI는 엔터프라이즈 VNET과 통합됩니다. 네트워크 정책은 측면 이동(lateral movement)을 제한합니다. 관리형 ID는 시크릿 확산을 제거합니다.

5. 별도의 시스템 및 사용자 노드 풀 생성, 배치 작업을 위한 스팟 풀 추가

• 이유: 중요한 플랫폼 파드를 격리하고, 중요하지 않은 워크로드를 위한 비용 효율적인 용량을 제공하며, 업그레이드 및 SLO 관리를 단순화합니다.

6. ACR(OCI)에 저장된 차트를 사용하여 패키징에 Helm 채택, Azure Pipelines를 통해 배포

• 이유: 환경별 값을 사용하여 일관되고 버전 관리되는 릴리스를 구현합니다. 파이프라인은 helm upgrade 전에 helm lint, dry-run, diff를 실행하며, Kubernetes 서비스 연결을 사용하여 대상 클러스터를 지정합니다.

7. GitOps 조정(reconciliation) 및 드리프트 감지를 위해 Flux v2 배포, 카나리 배포를 위해 Flagger 통합

• 이유: 선언적, 풀(pull) 기반 동기화는 CI의 자격 증명 필요성을 줄이고 상태 수렴(convergence)을 보장합니다. Flagger는 NGINX Ingress 메트릭을 사용하여 SLO에 대비한 가중치 기반 카나리 배포를 자동화하고, 오류나 지연 시간 급증 시 롤백합니다.

8. PDB 및 준비성/시작 프로브(readiness/startup probes)를 사용하여 롤링 업데이트 구성, 위험한 컴포넌트에는 블루-그린 배포 사용

• 이유: 롤링 업데이트는 용량을 보존합니다. 프로브는 사용자 트래픽을 보호합니다. Service의 레이블 전환을 이용한 블루-그린 방식은 API 게이트웨이와 같은 고위험 컴포넌트의 즉각적인 롤백을 가능하게 합니다.

9. 엄격한 mTLS, 재시도, 타임아웃을 갖춘 Istio 서비스 메시 도입, 원격 측정 데이터를 Application Insights로 내보내기

• 이유: 메시 전반의 암호화, 강력한 트래픽 정책, 통일된 관측성(observability)을 제공합니다. OpenTelemetry 수집기는 SLO 모니터링 및 인시던트 분류를 위해 추적/메트릭 데이터를 중앙 저장소로 전송합니다.

10. AKS 자동 업그레이드 채널 및 노드 이미지 업그레이드를 통한 통제된 업그레이드 전략 수립

• 이유: 정기적이고 예측 가능한 플랫폼 업데이트는 제로데이 노출을 줄입니다. 최대 서지(Max-surge) 및 PDB는 중단을 최소화합니다. 별도의 사용자 풀 업그레이드는 영향 반경(blast radius)을 제한합니다.

11. 이너 루프(inner-loop) 개발에 Bridge to Kubernetes 사용, Draft로 스캐폴딩

• 이유: 개발자는 모킹(mocking) 없이 클러스터 내 종속성에 대해 로컬에서 디버깅할 수 있습니다. Draft는 팀 전체에 걸쳐 일관된 컨테이너화 및 Helm 스캐폴딩을 가속합니다.

12. Dapr 및 KEDA를 사용하여 롱테일(long-tail) 서비스를 Azure Container Apps로 오프로드

• 이유: 이벤트 기반, 0으로 스케일링(scale-to-zero)되는 마이크로서비스(예: 수집 및 보강)는 카나리 배포를 위한 내장 트래픽 분할 기능으로 저렴하게 실행됩니다. Dapr 컴포넌트는 별도의 코드 없이 서비스 간 호출 및 pub/sub을 표준화합니다.

이 엔드투엔드 설계는 빌드 결정성(determinism)을 보안 배포, 선언적 운영, 점진적 배포와 결합하여, Adobe가 여러 리전에 걸쳐 신속하고 위험이 적은 릴리스와 강화된 런타임을 갖추도록 합니다.

← 코드형 인프라 및 구성 관리 · 모든 도메인 · 릴리스 관리 및 배포 전략 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →

Microsoft 찾아보기 →