AZ-900에서 틀리는 문제의 상당수는 개념을 몰라서가 아니라, 이름과 역할이 비슷한 서비스를 서로 바꿔 골라서 생깁니다. 보기 네 개 가운데 두 개가 Azure Policy와 RBAC, 또는 VPN Gateway와 ExpressRoute처럼 한 쌍으로 나오면 각 서비스의 정의를 아는 것만으로는 부족하고, 둘을 가르는 기준을 한 문장으로 말할 수 있어야 합니다.
이 글은 AZ-900 딥다이브 시리즈의 복습편입니다. 도메인별 글에서 따로 설명한 서비스 가운데 시험에서 서로의 오답 보기로 자주 함께 나오는 묶음만 골라, 구분 기준과 문제에 등장하는 단서 표현으로 다시 정리했습니다.
---
헷갈리는 서비스를 가르는 세 가지 질문
비슷한 서비스 둘을 만났을 때 아래 세 가지를 차례로 물어보면 대부분 갈립니다. 같은 길을 가는 두 사람이라도 목적지, 출발 시각, 이동 거리를 물어보면 누가 누군지 구분되는 것과 같습니다.
| 질문 | 무엇을 가르나 | 예시 | |------|------|------| | 무엇을 지키거나 통제하는가? | 대상(사람·리소스·데이터) | RBAC는 사람의 권한, Azure Policy는 리소스의 설정 | | 언제 쓰는가? | 시점(배포 전·배포 후·장애 시) | 가격 계산기는 배포 전, Cost Management는 배포 후 | | 범위가 어디까지인가? | 범위(데이터센터·영역·리전·전 세계) | 가용성 집합은 데이터센터 안, 가용성 영역은 리전 안 |
이 글의 비교표도 모두 이 세 가지 축으로 정리했습니다. 표를 통째로 외우기보다 "이 문제는 대상·시점·범위 중 무엇을 묻고 있는가"를 먼저 파악하는 연습을 하면 처음 보는 보기 조합에도 흔들리지 않습니다.
---
도메인 1: 클라우드 개념에서 헷갈리는 쌍
도메인 1은 서비스 이름보다 용어의 정확한 뜻을 묻습니다. 클라우드의 이점을 설명하는 용어들이 서로 비슷하게 들려서, 상황 설명을 읽고 어떤 이점에 해당하는지 고르는 문제가 대표적입니다.
확장성 vs 탄력성
| 구분 | 확장성 (Scalability) | 탄력성 (Elasticity) | |------|------|------| | 핵심 | 필요하면 리소스를 늘리거나 줄일 수 있는 능력 | 수요 변화에 맞춰 자동으로 늘고 줄어드는 능력 | | 누가 조정하나 | 사람이 직접 또는 미리 세운 계획에 따라 | 시스템이 부하를 보고 자동으로 | | 문제 속 단서 | "필요할 때 리소스를 추가할 수 있다" | "갑작스러운 트래픽 급증에 자동으로 대응" |
시험 팁: "자동"이라는 단어가 보이면 탄력성 쪽입니다. VM 크기를 키우는 수직 확장과 VM 개수를 늘리는 수평 확장은 둘 다 확장성을 이루는 방법이니, 방법과 이점을 섞지 않도록 주의하세요.
고가용성 vs 안정성 vs 예측 가능성
| 구분 | 고가용성 | 안정성 (Reliability) | 예측 가능성 | |------|------|------|------| | 핵심 질문 | 지금 서비스가 살아 있는가? | 장애가 나도 회복하는가? | 성능과 비용을 미리 알 수 있는가? | | 대표 수단 | SLA, 여러 대로 중복 배치 | 여러 영역·리전에 분산, 자동 복구 | 자동 크기 조정, 가격 계산기와 예산 | | 문제 속 단서 | "가동 시간 99.95% 보장" | "리전 장애에서도 복구" | "다음 달 비용을 미리 산출" |
시험 팁: 세 용어 모두 "장애"나 "SLA" 같은 단어와 함께 나오기 쉽습니다. 문장이 지금 동작하는 시간을 말하면 고가용성, 장애 뒤의 회복을 말하면 안정성, 계획과 예산을 말하면 예측 가능성입니다.
CapEx vs OpEx
| 구분 | CapEx (자본 지출) | OpEx (운영 지출) | |------|------|------| | 지출 방식 | 서버와 데이터센터를 미리 구매 | 사용한 만큼 그때그때 지불 | | 대표 환경 | 온프레미스 | 퍼블릭 클라우드의 소비 기반 모델 | | 문제 속 단서 | "초기 대규모 투자", "감가상각" | "초기 비용 없이", "사용량에 따라 청구" |
관련 글: 클라우드 컴퓨팅 개념, 클라우드 서비스의 이점
---
도메인 2: 아키텍처와 서비스에서 헷갈리는 쌍
출제 비중이 가장 큰 도메인이라 헷갈리는 쌍도 가장 많습니다. 얼마나 넓은 장애에 대비하는지(범위), 무엇과 무엇을 어떤 경로로 잇는지(연결 방식)가 주요 기준입니다.
가용성 집합 vs 가용성 영역 vs 리전 쌍
| 구분 | 가용성 집합 | 가용성 영역 | 리전 쌍 | |------|------|------|------| | 대비하는 장애 | 랙 단위 하드웨어 장애, 계획된 유지 관리 재부팅 | 데이터센터 하나 전체의 장애 | 리전 전체에 영향을 주는 대규모 재해 | | 범위 | 한 데이터센터 안 | 한 리전 안의 물리적으로 분리된 데이터센터 | 같은 지리 안의 다른 리전 | | VM 2대 이상 배치 시 SLA | 99.95% | 99.99% | 해당 없음 (재해 복구 설계) |
시험 팁: "데이터센터 하나가 통째로 멈춰도 계속 동작" → 가용성 영역, "리전 전체 재해에 대비" → 리전 쌍, "같은 데이터센터 안에서 하드웨어 장애와 유지 관리 재부팅에 대비" → 가용성 집합입니다.
VPN Gateway vs ExpressRoute vs VNet 피어링
| 구분 | VPN Gateway | ExpressRoute | VNet 피어링 | |------|------|------|------| | 무엇을 잇나 | 온프레미스 네트워크나 개인 PC ↔ Azure VNet | 온프레미스 네트워크 ↔ Azure | Azure VNet ↔ Azure VNet | | 경로 | 공용 인터넷 위의 암호화 터널 | 인터넷을 거치지 않는 전용 사설 연결 | Microsoft 백본 네트워크 | | 문제 속 단서 | "인터넷을 통해 암호화된 연결" | "인터넷을 거치지 않음", "더 높은 대역폭" | "두 가상 네트워크를 직접 연결" |
시험 팁: VPN에도 두 종류가 있습니다. 사이트 간(Site-to-Site)은 사무실 네트워크 전체를, 지점 간(Point-to-Site)은 재택근무자 PC 한 대를 Azure에 연결합니다.
퍼블릭 엔드포인트 vs 프라이빗 엔드포인트
| 구분 | 퍼블릭 엔드포인트 | 프라이빗 엔드포인트 | |------|------|------| | 주소 | 공용 IP 주소 | 내 VNet 주소 공간의 사설 IP 주소 | | 접근 범위 | 인터넷 어디서나 (방화벽 규칙으로 제한 가능) | 그 VNet과 연결된 네트워크에서만 | | 문제 속 단서 | "인터넷에서 접근 가능한 주소" | "VNet 안의 사설 IP로 PaaS 서비스에 접근" |
관련 글: 퍼블릭 엔드포인트 vs 프라이빗 엔드포인트
Virtual Machines vs App Service vs Functions vs 컨테이너
| 서비스 | 모델 | 내가 관리하는 범위 | 문제 속 단서 | |------|------|------|------| | Virtual Machines | IaaS | 운영체제부터 직접 | "OS를 완전히 제어", "기존 서버를 그대로 이전" | | App Service | PaaS | 코드와 앱 설정 | "웹앱·API를 인프라 관리 없이 호스팅" | | Azure Functions | 서버리스 | 함수 코드만, 실행한 만큼 과금 | "이벤트가 발생할 때만 코드 실행" | | Container Instances | PaaS | 컨테이너 하나 | "오케스트레이션 없이 컨테이너를 빠르게 실행" | | Azure Kubernetes Service | 관리형 Kubernetes | 컨테이너 묶음과 배포 정책 | "많은 컨테이너를 배포·확장·관리" |
관련 글: Azure 가상 머신 완전 정리, 컴퓨팅과 네트워킹
LRS vs ZRS vs GRS vs GZRS
| 옵션 | 복사본 위치 | 견디는 장애 | |------|------|------| | LRS | 주 리전의 데이터센터 한 곳에 3개 | 디스크·서버 고장 | | ZRS | 주 리전의 가용성 영역 3곳에 나눠서 | 데이터센터(영역) 하나의 장애 | | GRS | 주 리전에 LRS 방식 3개 + 보조 리전에 3개 | 주 리전 전체의 장애 | | GZRS | 주 리전에 ZRS 방식 3개 + 보조 리전에 3개 | 영역 장애와 리전 장애 모두 |
시험 팁: 이름 앞에 RA-가 붙은 RA-GRS와 RA-GZRS는 평상시에도 보조 리전의 데이터를 읽을 수 있습니다. "장애가 없어도 보조 리전에서 읽기"가 나오면 RA- 옵션입니다.
AzCopy vs Storage Explorer vs File Sync vs Data Box vs Azure Migrate
| 도구 | 형태 | 언제 쓰나 | |------|------|------| | AzCopy | 명령줄 도구 | 스크립트로 Blob과 파일을 한 번에 대량 복사 | | Azure Storage Explorer | 데스크톱 GUI 앱 | 화면에서 스토리지 계정을 탐색하고 관리 | | Azure File Sync | 동기화 서비스 | Windows 파일 서버와 Azure Files를 계속 동기화 | | Azure Data Box | 물리 장치 | 네트워크로 옮기기 어려운 대용량 데이터를 배송 | | Azure Migrate | 마이그레이션 허브 | 서버·DB·웹앱을 평가하고 Azure로 이전 |
시험 팁: "한 번 복사"인지 "계속 동기화"인지가 AzCopy와 File Sync를 가릅니다. "인터넷 대역폭이 부족한데 데이터가 수십 TB"라면 Data Box입니다.
Microsoft Entra ID vs Microsoft Entra Domain Services
| 구분 | Microsoft Entra ID | Microsoft Entra Domain Services | |------|------|------| | 성격 | 클라우드 ID·액세스 관리 서비스 | 관리형 도메인 서비스 | | 주요 기능 | SSO, MFA, 조건부 액세스, 앱 로그인 | 도메인 가입, 그룹 정책, LDAP, Kerberos/NTLM 인증 | | 문제 속 단서 | "SaaS 앱에 한 번 로그인으로 접근" | "도메인 컨트롤러를 직접 관리하지 않고 레거시 앱을 이전" |
관련 글: 심층 방어와 Entra ID 심화 개념
---
도메인 3: 관리와 거버넌스에서 헷갈리는 쌍
도메인 3의 도구들은 모두 "통제"나 "관리"를 위한 것이라 이름만으로는 잘 갈리지 않습니다. 무엇을 통제하는지, 그리고 배포 전과 후 중 언제 쓰는지로 구분하세요.
Azure Policy vs RBAC vs 리소스 잠금
| 구분 | RBAC | Azure Policy | 리소스 잠금 | |------|------|------|------| | 묻는 질문 | 누가 무엇을 할 수 있나? | 리소스가 어떤 규칙을 지켜야 하나? | 실수로 지우거나 바꾸지 않게 하려면? | | 통제 대상 | 사용자·그룹·관리 ID의 권한 | 리소스의 설정 (리전, SKU, 태그 등) | 특정 리소스·리소스 그룹·구독 | | 대표 예 | 개발팀에 읽기 권한자 역할 부여 | "허용된 리전에만 배포" | 삭제 잠금(CanNotDelete), 읽기 전용 잠금(ReadOnly) |
!RBAC vs Azure Policy vs 리소스 잠금
시험 팁: 리소스 잠금은 소유자(Owner) 역할을 가진 사람에게도 똑같이 적용됩니다. "관리자라도 실수로 삭제하지 못하게"라는 문장이 나오면 리소스 잠금입니다. 또 RBAC로 권한이 있어도 Azure Policy가 거부하는 설정이면 리소스를 만들 수 없습니다.
Azure Policy vs Microsoft Purview
| 구분 | Azure Policy | Microsoft Purview | |------|------|------| | 다스리는 것 | Azure 리소스의 구성 | 데이터 (어디에 무엇이 있는지, 민감도, 흐름) | | 문제 속 단서 | "규칙에 맞지 않는 리소스를 차단하거나 감사" | "여러 환경에 흩어진 데이터를 찾아 분류" |
Azure Advisor vs Service Health vs Azure Monitor
| 구분 | Azure Advisor | Azure Service Health | Azure Monitor | |------|------|------|------| | 알려 주는 것 | 비용·보안·안정성·성능·운영 우수성 개선 권장 사항 | Azure 플랫폼 쪽 장애, 계획된 유지 관리, 상태 권고 | 내 리소스의 지표와 로그, 경보 | | 비유 | 건강 검진 결과지 | 날씨 예보 | 스마트워치 | | 문제 속 단서 | "비용 절감과 보안 개선을 추천" | "내 리전의 Azure 서비스 장애 알림" | "CPU 80%를 넘으면 경보", "로그 쿼리" |
시험 팁: Service Health는 Azure 쪽에서 생긴 문제, Monitor는 내 리소스에서 나온 데이터입니다. Log Analytics와 Application Insights는 Azure Monitor에 속한 기능이라는 점도 함께 기억하세요.
가격 계산기 vs Cost Management