DevOps 전략 설계·구현 역량 검증. CI/CD, IaC, 모니터링 등 DevOps 전 영역 커버.
작업 추적성·작업 흐름 설계, GitHub Issues·Azure Boards 통합, DevOps 메트릭·DORA·MTTR, 대시보드·KQL 쿼리, 협업 Wiki·Mermaid·Microsoft Teams 통합, 릴리스 노트·웹훅
분기 전략 (Trunk-based·GitHub Flow), PR 워크플로·Branch Policy, branch protection rule·CODEOWNERS, Git LFS·Scalar·Shallow/Partial Clone, 리포지토리 권한·민감 데이터 제거(BFG)
GitHub Actions·Azure Pipelines (YAML), 러너·에이전트·환경·승인, 패키지 관리 (Azure Artifacts·GitHub Packages·SemVer), Quality Gates·테스트 전략 (단위·통합·부하), Blue-Green·Canary·Ring·Feature Flag·Slot Swap, IaC: ARM·Bicep·Terraform·DSC
Service Principal·Managed Identity·GitHub App, PAT·서비스 연결·권한 위임, Azure Key Vault·OIDC·Workload Identity Federation, GitHub Advanced Security (CodeQL·Dependabot), Defender for Cloud DevOps·SAST·SCA·컨테이너 스캔
Azure Monitor·Log Analytics, Application Insights·distributed tracing, Container/VM/Network Insights, GitHub Insights·Pipelines 알림, KQL 쿼리·성능 분석
무료 샘플 세트의 실전형 문제를 바로 풀어보세요. 모든 정답에 상세 해설이 제공됩니다.
한 e-커머스 기업은 Azure Pipelines를 사용하여 웹 애플리케이션의 CI/CD 파이프라인을 운영하고 있습니다.
QA팀은 릴리스 전 단계로 다양한 브라우저(Chromium, Firefox, WebKit) 환경에서 웹 UI에 대한 end-to-end 자동화 테스트를 수행하려고 합니다. 테스트는 파이프라인의 일부로 실행되어야 하며, 최신 브라우저 엔진에 대한 native 지원과 함께 안정적인 자동 대기(auto-wait) 기능을 제공해야 합니다.
이 요구사항을 가장 적절하게 충족하는 web UI testing framework는 무엇입니까?
정답: B. Playwright
한 e-커머스 기업이 Chromium, Firefox, WebKit 세 가지 브라우저 엔진을 모두 native로 지원하면서 auto-wait 기능이 필요한 상황입니다. Playwright는 Microsoft가 개발한 end-to-end 테스트 프레임워크로, 세 가지 브라우저 엔진(Chromium, Firefox, WebKit)을 단일 API로 통제하며 각 엔진의 바이너리를 직접 패키징하여 native 수준의 지원을 제공합니다. 또한 요소가 클릭 가능·표시 가능 상태가 될 때까지 자동으로 대기하는 built-in auto-wait 메커니즘을 기본 제공합니다.
Playwright는 JavaScript/TypeScript, Python, Java, .NET 등 다양한 언어 바인딩을 제공하고, Azure Pipelines의 YAML 파이프라인에서 npx playwright test 명령으로 직접 실행할 수 있습니다. 병렬 실행, 비디오 녹화, 네트워크 인터셉트 등의 기능도 내장되어 있습니다.
시험에서 Selenium과 Playwright를 혼동하기 쉽습니다. WebKit native 지원 또는 built-in auto-wait가 조건이면 Playwright, 다양한 언어/브라우저의 광범위한 레거시 지원이 필요하면 Selenium을 선택하세요. Cypress는 WebKit을 지원하지 않으므로 이 시나리오에서 탈락합니다.
한 글로벌 금융 회사의 보안 팀이 Azure DevOps에 대한 접근을 강화하려고 합니다. 모든 개발자는 회사가 지정한 사무실 네트워크 또는 회사 VPN을 통해서만 Azure DevOps Organization에 접근할 수 있어야 하며, 그 외의 위치에서는 접근이 차단되어야 합니다.
기존 사용자 계정과 환경에 대한 변경을 최소화하면서 이러한 네트워크 기반 접근 제한을 적용하기 위해 사용해야 하는 가장 적절한 기능은 무엇입니까?
정답: B. Microsoft Entra Conditional Access
Microsoft Entra Conditional Access는 네트워크 위치(IP 범위·신뢰할 수 있는 위치)를 조건으로 Azure DevOps 등 Entra ID와 연동된 앱에 대한 접근을 허용하거나 차단하는 정책을 설정할 수 있습니다. 기존 사용자 계정이나 Azure DevOps 프로젝트 구성을 변경하지 않고도 조직 전체에 일관된 네트워크 기반 접근 제어를 적용할 수 있어 이 시나리오에 가장 적합합니다.
Conditional Access 정책은 네임드 로케이션(Named Location)을 통해 사무실 공인 IP 범위나 VPN 게이트웨이 IP를 신뢰할 수 있는 위치로 등록하고, 해당 위치 외에서 오는 요청을 자동 차단합니다. 이 정책은 사용자가 로그인할 때 토큰 발급 단계에서 평가되므로, Azure DevOps 내부 설정과 독립적으로 동작합니다.
시험에서 Project Security와 Conditional Access를 혼동하기 쉽습니다. Project Security는 DevOps 내 특정 프로젝트의 권한(읽기·쓰기)을 제어하는 기능으로 네트워크 위치 기반 차단을 지원하지 않습니다. 네트워크 위치 기반 접근 제한은 반드시 Microsoft Entra Conditional Access를 선택하세요.
한 글로벌 금융 서비스 회사가 Azure Pipelines를 사용하여 운영 환경의 SQL Database에 배포하는 CI/CD 파이프라인을 구축하고 있습니다. 파이프라인 실행 중에 데이터베이스 연결 문자열과 외부 결제 게이트웨이 API Key가 필요하며, 보안 팀은 이러한 민감 정보가 파이프라인 YAML 파일이나 변수 그룹에 평문으로 저장되어서는 안 되고, 중앙에서 관리되며 감사 가능한 방식으로 보호되어야 한다고 요구합니다.
운영 오버헤드를 최소화하면서 이러한 민감 정보를 Azure Key Vault에 저장하기 위해 사용해야 하는 Key Vault 객체 유형은 무엇입니까?
정답: C. Key Vault Secret
Azure Key Vault에서 데이터베이스 연결 문자열, API Key와 같은 임의의 문자열 형태의 민감 정보를 저장하는 전용 객체 유형은 Key Vault Secret입니다. Azure Pipelines는 변수 그룹을 Key Vault에 연결하여 Secret을 파이프라인 변수로 참조할 수 있으므로, YAML 파일에 평문 저장 없이 중앙 관리 및 감사 로그를 동시에 충족합니다.
Key Vault의 세 가지 객체 유형은 각각 역할이 다릅니다. Secret은 연결 문자열, API Key, 비밀번호 등 임의 문자열 값을 저장하고, Key는 암호화·서명에 사용하는 암호화 키(RSA, EC)를 관리하며, Certificate는 X.509 인증서를 저장합니다. Managed HSM은 FIPS 140-2 Level 3 보안이 필요한 고가용성 전용 HSM 클러스터이며 일반 Secret 저장 용도가 아닙니다.
시험에서 연결 문자열·API Key·비밀번호를 저장해야 한다면 반드시 Secret을 선택합니다. 암호화 작업(서명·암복호화)이 필요하면 Key, TLS/SSL 인증서 관리이면 Certificate를 선택합니다.
한 글로벌 전자상거래 회사의 운영팀이 Azure App Service에서 호스팅되는 운영 환경 웹 애플리케이션을 운영하고 있습니다. 매월 정기 배포 시 짧은 다운타임이 발생하고 있으며, 새 버전 배포 후 문제가 발견되면 이전 버전으로의 롤백에 상당한 시간이 소요됩니다.
다운타임을 최소화하고 문제 발생 시 롤백 시간을 최소화하기 위해 사용해야 하는 가장 적절한 Azure App Service 기능은 무엇입니까?
정답: C. Deployment slots - Slot swap
Azure App Service의 배포 슬롯(deployment slot)을 사용하면 운영 슬롯과 별도의 스테이징 슬롯에 새 버전을 배포한 후, 워밍업이 완료된 시점에 슬롯 스왑(slot swap)으로 무중단 전환할 수 있습니다. 슬롯 스왑은 DNS 레벨에서 라우팅을 즉시 전환하므로 다운타임이 거의 발생하지 않으며, 문제 발견 시 다시 스왑하면 이전 버전으로 수초 내에 롤백됩니다.
배포 슬롯은 Azure App Service의 Standard, Premium, Isolated 플랜에서 지원되며, 각 슬롯은 독립적인 호스트 이름과 앱 설정을 가질 수 있습니다. 스왑 시 슬롯별 설정(슬롯 고정 설정)은 교환되지 않고 해당 슬롯에 고정되므로, 운영 환경의 연결 문자열이나 설정이 스테이징으로 노출되지 않습니다.
시험에서 Azure App Service 무중단 배포·빠른 롤백 시나리오가 나오면 Deployment slots - Slot swap을 선택하세요. Azure Traffic Manager는 다중 리전 라우팅용이고, Azure Load Balancer는 네트워크 레이어 부하 분산용으로 App Service 배포 전략과는 다른 용도입니다.
한 SaaS 회사가 공개 NuGet 패키지를 게시하고 있으며, Semantic Versioning을 따르는 버전 관리 정책을 적용하고 있습니다. 최근 릴리스된 패키지에서 기존 API 동작에는 영향을 주지 않는 사소한 버그가 발견되어 수정 사항을 배포해야 합니다.
현재 버전이 3.5.2일 때, 이 버그 수정 릴리스에 적용해야 하는 가장 적절한 버전 번호는 무엇입니까?
정답: B. 3.5.3
Semantic Versioning(SemVer)에서 버전 번호는 MAJOR.MINOR.PATCH 세 구성 요소로 이루어집니다. 이 시나리오에서 버그 수정은 기존 API 동작에 영향을 주지 않는 후방 호환 수정이므로 PATCH 버전만 1 증가시켜야 합니다. 현재 버전 3.5.2에서 PATCH를 1 증가시키면 3.5.3이 됩니다.
SemVer 규칙에 따르면 MAJOR 버전은 하위 호환이 불가능한 API 변경 시, MINOR 버전은 후방 호환 신기능 추가 시, PATCH 버전은 후방 호환 버그 수정 시에만 증가시킵니다. 3.6.0은 새 기능을 추가한 경우, 4.0.0은 Breaking Change가 있는 경우에 해당합니다. 3.5.2는 현재 버전과 동일하므로 변경 없는 재릴리스에 해당하여 사용 불가합니다.
시험에서 '기존 API 영향 없는 버그 수정'이면 반드시 PATCH(세 번째 숫자)만 증가시킵니다. '새 기능 추가'이면 MINOR, 'Breaking Change'이면 MAJOR를 올립니다.
Designing and Implementing Microsoft DevOps Solutions (AZ-400) 시험은 총 50문항으로 구성되어 있으며, 시험 시간은 100분입니다.
AZ-400 시험의 합격 점수는 1000점 만점 중 700점 이상입니다.
AZ-400 샘플 세트 20문항은 해설까지 포함해 무료로 풀 수 있습니다. 370문항 이상의 전체 문제 세트는 CloudMasterIT 구독으로 이용할 수 있습니다.
AZ-400 자격증은 취득 후 1년간 유효하며, 이후 재인증이 필요합니다.