Microsoft AZ-204: Azure Storage 및 Blob Storage — 학습 가이드

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

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

개요

Azure Storage는 비정형 및 정형 데이터를 위한 내구성이 뛰어나고 대규모로 확장 가능한 클라우드 스토리지를 제공합니다. 애플리케이션 개발 시에는 올바른 스토리지 계정 유형 선택, RTO/RPO 목표를 충족하기 위한 중복성 구성, 비용/성능에 맞는 Blob 유형 및 액세스 계층 선택, Azure AD 및 SAS를 사용한 액세스 보안 확보에 중점을 두어야 합니다. 수명 주기 정책을 사용하여 계층 간 데이터 이동을 자동화하고, 적절한 경우 Blob 스토리지에서 직접 정적 웹 사이트를 제공하며, 파일 시맨틱이나 메시지 기반 디커플링이 필요한 곳에는 Azure Files 및 Queue Storage를 적용해야 합니다.

스토리지 계정 유형 및 중복성 기본 사항

General-purpose v2(GPv2)는 대부분의 워크로드에 대한 표준 계정 유형입니다. Blob, 파일, 큐, 테이블, 모든 액세스 계층, 수명 주기 관리 및 최신 기능을 지원합니다. 레거시 BlobStorage 계정은 Blob 서비스와 계층화만 노출하지만, GPv2에서 제공하는 다양한 기능과 비용 최적화가 부족합니다. 따라서 새로운 배포에는 GPv2를 사용하는 것이 좋습니다. FileStorage 계정은 Azure Files 전용의 프리미엄 SSD 기반 계정으로, 엔터프라이즈 파일 워크로드(예: 프로필 공유, 기간 업무 앱)에 대해 일관되고 짧은 대기 시간의 IOPS 및 처리량을 제공합니다. SMB/NFS 공유에 대한 프리미엄 성능이 필요한 경우 FileStorage를 선택하고, 그렇지 않은 경우 GPv2가 기본입니다.

중복성 선택은 장애 도메인 전반에 걸쳐 데이터 내구성과 가용성을 결정합니다.

LRS(로컬 중복 스토리지)는 단일 데이터 센터 내에 3개의 복사본을 동기적으로 저장합니다. 비용이 가장 저렴하지만 영역 또는 지역 보호 기능은 없습니다. 개발/테스트, 임시 워크로드 또는 상위 계층에서 복제를 수행하는 경우에 사용합니다.
ZRS(영역 중복 스토리지)는 한 지역 내의 가용성 영역에 걸쳐 동기적으로 복제하여 영역 장애로부터 데이터를 보호하고 높은 가용성과 RPO 0을 제공합니다. 지역 내 복원력이 필요한 영역별 지역의 프로덕션 환경에 선택합니다.
GRS(지역 중복 스토리지)는 기본 지역에 3개의 동기 복사본을 저장하고(LRS와 같음) 쌍을 이루는 보조 지역에 비동기적으로 복제합니다(거기서는 LRS). 일반적인 RPO는 15분 미만이며, 보조 지역은 기본적으로 읽을 수 없습니다. 읽기 액세스가 필요하지 않은 재해 복구 시나리오에 선택합니다.
RA-GRS(읽기 액세스 지역 중복 스토리지)는 -secondary 엔드포인트를 통해 보조 지역에 대한 읽기 액세스를 추가합니다. 지역 간 재해 허용 오차와 기본 지역 장애 시 읽기 위주 워크로드가 필요하거나, 최종 일관성이 허용되는 지역 근접성 읽기에 사용합니다.

영역 장애 보호와 지역 간 DR이 모두 필요한 경우, 솔루션 수준에서 로컬 ZRS와 추가적인 지역 복제 계정 패턴을 함께 사용하는 것을 고려하십시오. 계정 장애 조치 테스트를 계획하고, DNS 엔드포인트 전환을 이해하며, 지역 이벤트 중 최종 일관성 및 클럭 스큐를 처리하기 위한 애플리케이션 재시도 정책을 검증해야 합니다.

Blob 데이터 모델, 계층 및 수명 주기 관리

Blob은 고유한 시맨틱을 가진 세 가지 유형이 있습니다. 블록 Blob은 이미지, 비디오, 백업과 같은 대용량 객체의 스트리밍 및 임의 읽기에 최적화되어 있습니다. 업로드는 블록으로 분할되어 커밋되므로 병렬 업로드와 효율적인 재시도가 가능합니다. 추가 Blob은 원격 측정 및 로그 캡처와 같은 추가 전용 워크로드에 최적화되어 있습니다. 추가 작업만 허용되므로 동시성 관리가 단순화됩니다. 페이지 Blob은 임의 읽기/쓰기 I/O를 위해 512바이트로 정렬된 페이지를 노출하며, Azure VM 디스크에서 사용하는 Azure 가상 하드 디스크(VHD)의 기반이 됩니다. IaaS 디스크 및 대규모 임의 I/O 워크로드에 지원되는 유일한 Blob 유형입니다.

Blob 액세스 계층은 비용과 성능을 제어합니다. 핫(Hot)은 가장 낮은 읽기/쓰기 대기 시간과 가장 높은 스토리지 비용으로 빈번한 액세스에 최적화되어 있습니다. 쿨(Cool)은 최소 30일 이상 보관되는 드물게 액세스하는 데이터를 대상으로 하며, 스토리지 비용은 낮지만 트랜잭션/읽기 비용과 최소 보존 요금이 더 높습니다. 아카이브(Archive)는 장기 보존을 위한 가장 저렴한 계층입니다. 객체는 오프라인 상태이며 읽기 전에 핫 또는 쿨 계층으로 리하이드레이션(rehydration)해야 합니다. 리하이드레이션은 표준 또는 높은 우선순위로 요청할 수 있으며, 비용과 속도를 맞바꿀 수 있습니다. 계정 수준에서 기본 액세스 계층(핫 또는 쿨)을 설정하고 Blob별로 재정의할 수 있으며, 아카이브는 Blob별로만 설정 가능합니다.

수명 주기 관리 정책은 데이터 이동 및 보존을 자동화하여 비용을 제어하고 거버넌스를 충족합니다. 계정 수준에서 다음과 같은 규칙을 정의합니다.

마지막으로 수정된 후 N일이 지나면 Blob 또는 Blob 버전/스냅샷을 쿨 또는 아카이브 계층으로 전환
보존 기간 임계값이 지나면 Blob, 스냅샷 또는 버전 삭제
컨테이너 접두사 및 Blob 인덱스 태그로 필터링하여 특정 데이터 세트를 대상으로 지정 (예: env=prod 및 policy=retention-7y 태그 지정) 수명 주기 규칙을 버전 관리 및 일시 삭제와 결합하여 우발적인 삭제로부터 데이터를 보호하면서 보존 정책을 강제 적용할 수 있습니다. 아카이브 계층에는 최소 보존 기간 및 조기 삭제 요금이 있다는 점을 기억하고, 불필요한 리하이드레이션을 최소화하도록 정책을 설계해야 합니다.

변경 내용 추적 및 다운스트림 처리를 위해 스토리지 계정 변경 피드를 활성화하여 Blob 생성, 업데이트, 삭제 및 복사 작업의 순서가 지정된 불변 로그를 사용할 수 있습니다. 이는 체크포인팅을 통해 정확히 한 번(exactly-once) 또는 최소 한 번(at-least-once) 시맨틱이 필요한 규정 준수 및 비동기 프로세서를 지원합니다.

Blob 스토리지의 정적 웹 사이트 호스팅은 전용 웹 엔드포인트를 통해 제공되는 특수 $web 컨테이너를 노출합니다. 인덱스 및 오류 문서를 구성하고 정적 자산을 직접 게시합니다. 정적 웹 사이트 엔드포인트는 Blob의 공용 액세스 설정과 독립적으로 사이트 콘텐츠에 대한 익명 읽기 액세스를 제공하며, Blob 엔드포인트를 통한 액세스는 비활성화된 상태로 유지할 수 있습니다. 사용자 지정 도메인 및 글로벌 가속을 위해 엔드포인트 앞에 Azure Front Door 또는 Azure CDN을 배치합니다. 정적 웹 사이트 엔드포인트에는 프라이빗 엔드포인트가 지원되지 않으므로, 프라이빗 액세스가 필요한 경우 엣지 서비스를 사용하여 전송을 보호하고 가속화해야 합니다.

보안, ID 및 제어된 데이터 액세스

Azure Storage는 기본적으로 Microsoft 관리형 키를 사용하는 256비트 AES로 미사용 데이터를 암호화합니다. 더 엄격한 제어를 위해 Azure Key Vault 또는 Managed HSM에 저장된 고객 관리형 키(CMK)를 활성화하여 키 순환 및 직무 분리를 관리하고, 스토리지 계정의 관리 ID에 wrap/unwrap 권한을 부여하십시오. 규제가 엄격한 워크로드의 경우, 인프라 암호화를 활성화하여 두 번째 독립적인 암호화 계층을 적용하십시오. 종단 간 암호화 제어가 필요한 경우 서버 측 암호화와 클라이언트 측 암호화를 함께 사용하십시오.

Azure AD 권한 부여는 Blob 및 Queue 서비스와 Files REST API에 대해 데이터 평면을 RBAC와 통합합니다. Storage Blob Data Reader 또는 Storage Blob Data Contributor와 같은 최소 권한 역할을 관리 ID, 사용자 또는 그룹에 부여하십시오. 코드에서는 DefaultAzureCredential을 사용하여 OAuth 2.0 토큰을 획득하고 키를 포함하지 않도록 하십시오. Azure Files에 대한 SMB 액세스의 경우 Active Directory를 사용하여 ID 기반 인증을 활성화하십시오. 스토리지 계정을 온프레미스 AD DS(하이브리드 ID의 경우 Azure AD Kerberos를 통해) 또는 Azure AD DS에 조인하고, 공유 수준 권한 부여를 위해 NTFS ACL 및 RBAC(예: Storage File Data SMB Share Contributor)를 사용하십시오. 전송 중 암호화를 지원하는 SMB 3.x를 사용하고, 445번 포트를 차단하는 네트워크를 통과하기 위해 Private Endpoints, VPN 또는 ExpressRoute 사용을 고려하십시오.

공유 액세스 서명(SAS)은 계정 키를 노출하지 않고 범위가 지정되고 시간이 제한된 액세스를 위임합니다. 서비스 SAS는 정확한 권한과 시작/만료 시간을 사용하여 특정 서비스 및 리소스(예: 단일 blob 또는 컨테이너)에 대한 액세스를 부여합니다. 계정 SAS는 계정 수준에서 작동하며 여러 서비스(blob, 파일, 큐, 테이블)와 목록 또는 생성과 같은 서비스 API에 걸쳐 적용됩니다. 사용자 위임 SAS는 Blob storage에만 해당하며, 적절한 RBAC를 가진 보안 주체에 대해 Azure AD를 통해 얻은 사용자 위임 키로 서명됩니다. 이는 키 종속성을 제거하고 Azure AD에서 액세스 제어를 중앙 집중화합니다. IP 범위, 허용된 프로토콜(HTTPS 전용), 짧은 수명 등의 제약 조건을 적용하십시오. 저장된 액세스 정책은 SAS 제약 조건을 중앙 집중화하고 정책을 업데이트하거나 삭제하여 해지를 활성화합니다. 이는 서비스 SAS 및 계정 SAS에 적용됩니다. 사용자 위임 SAS는 저장된 액세스 정책을 사용하지 않으며, 사용자 위임 키를 만료시키거나 Azure AD 역할 할당을 제거하여 해지합니다. 항상 계정 키보다 SAS를 선호하고, 앱이 Azure AD 토큰을 획득할 수 있을 때는 사용자 위임 SAS를 선호하십시오.

Azure Files 및 Queue Storage 핵심 사항

Azure Files는 완전 관리형 SMB 공유와 POSIX 시나리오를 위한 NFS 옵션을 제공합니다. 리프트 앤 시프트 마이그레이션 및 앱 호환성을 위해 SMB 공유를 사용하세요. Premium FileStorage 계정은 예측 가능한 짧은 지연 시간 성능을 제공하는 반면, 표준 공유는 범용 파일 데이터에 경제적입니다. SMB 클라이언트나 REST API/SDK를 통해 공유 및 파일을 관리할 수 있습니다. Azure File Sync는 클라우드 공유를 Windows Server에 캐싱하여 하이브리드 파일 서비스를 가능하게 합니다. 이를 통해 로컬 성능을 제공하고 콜드 데이터를 클라우드로 계층화하며, 다중 사이트 동기화 및 기존 NAS 교체 주기 없는 백업/오프사이트 DR을 구현할 수 있습니다. Azure AD 기반 ID를 NTFS ACL과 결합하여 최소 권한을 강제하고, Private Endpoints를 사용하여 데이터 유출 위험을 억제하세요.

Azure Queue Storage는 분리되고 복원력 있는 애플리케이션 워크플로를 가능하게 합니다. 각 메시지는 최대 64KB까지 가능하며(더 큰 페이로드는 Blob URI를 참조해야 합니다), 메시지 TTL(Time-to-Live)은 자동 만료를 결정합니다. 초 단위부터 최대 7일까지의 양수 값을 지정하거나, 만료되지 않게 하려면 -1을 지정합니다. 작업자가 메시지를 검색하면 해당 메시지는 표시 제한 시간 동안 보이지 않게 됩니다. 만약 처리가 실패하고 제한 시간 전에 메시지가 삭제되지 않으면, 다른 소비자를 위해 다시 나타납니다. 최악의 처리 시간을 초과하도록 표시 제한 시간을 조정하고, 멱등성 핸들러와 지수 백오프를 사용하여 경합을 줄이세요. Dequeue 횟수를 추적하여 포이즌 메시지를 탐지하고, 임계값을 초과하면 격리 및 분석을 위해 전용 포이즌 큐로 메시지를 이동합니다. Azure Functions 큐 트리거는 -poison 큐를 사용하여 이 패턴을 자동으로 구현합니다. 더 높은 처리량이나 순서 보장이 있는 FIFO 요구사항의 경우 Service Bus 큐를 고려하고, 그렇지 않은 경우 Azure Queue Storage가 가볍고 비용 효율적입니다.

실용적인 문제 시나리오

National Geographic은 서버리스 이미지 처리, 비용 최적화된 스토리지, 온프레미스 편집 도구를 위한 하이브리드 액세스를 갖춘 트래픽이 많은 사진 마이크로사이트를 게시해야 합니다. 또한 파트너 기관을 위한 안전한 시간 제한 공유 링크와 백그라운드 처리를 위한 견고한 메시지 처리가 필요합니다.

RA-GRS를 사용하는 GPv2 스토리지 계정 생성

이유: GPv2는 수명 주기 및 계층화 기능이 있는 Blob, Files, Queue 서비스를 사용할 수 있게 합니다. RA-GRS는 지역 간 재해 허용 오차를 제공하고, 지역 장애 발생 시 대부분 읽기 전용인 자산의 연속성을 위해 보조 엔드포인트에 대한 읽기 액세스를 제공합니다.

정적 웹 사이트 호스팅을 활성화하고 사이트 자산을 $web 컨테이너에 배포

이유: Blob 정적 웹 사이트는 웹 서버 관리를 없애고, Hot 계층에서 짧은 지연 시간의 읽기를 제공하며, 전 세계적으로 확장됩니다. 나중에 Azure Front Door와 연동하여 사용자 지정 도메인, WAF 및 엣지 캐싱을 사용할 수 있습니다.

원본 RAW 이미지를 블록 Blob으로 저장하고, 쓰기 전용 원격 분석 데이터는 추가 Blob으로 저장

이유: 블록 Blob은 대규모 병렬 업로드와 웹에 최적화된 파생물의 효율적인 전송을 지원합니다. 추가 Blob은 처리 파이프라인에서 충돌 없이 동시 로그 쓰기를 단순화합니다.

원본을 30일 후 Cool로, 180일 후 Archive로 이동하고, 1년 이상 된 버전은 삭제하는 수명 주기 정책 정의

이유: 자동 계층화는 액세스 패턴에 따라 스토리지 비용을 절감하면서 규정 준수 사본을 유지합니다. 버전 및 스냅샷 정리는 수동 개입 없이 데이터 증가를 제어합니다.

Azure AD 및 파트너를 위한 사용자 위임 SAS로 데이터 액세스 보안 강화

이유: 공유 서비스의 관리 ID에 Storage Blob Data Reader 역할을 할당하고, 사용자 위임 키를 얻은 다음, IP 제한이 있는 단기 HTTPS 전용 SAS 토큰을 발급합니다. 이렇게 하면 계정 키를 배포하는 것을 피하고 권한 부여를 Azure AD와 연결할 수 있습니다.

Key Vault 및 인프라 암호화로 고객 관리형 키(CMK) 활성화

이유: CMK는 더 엄격한 규정 준수 및 순환 요구 사항을 충족하며, 이중 암호화는 민감한 미디어에 대한 심층 방어를 제공합니다.

Azure Functions 큐 트리거를 사용하여 백그라운드 이미지 처리를 위해 Azure Queue Storage 통합; 최대 처리 시간을 초과하도록 표시 제한 시간을 설정하고 포이즌 메시지 처리 구성

이유: 큐는 업로드 경로를 컴퓨팅과 분리합니다. 표시 제한 시간은 중복 작업을 방지하고, Functions 런타임은 실패한 항목을 조사할 수 있도록 -poison 큐로 자동 라우팅합니다.

프리미엄 FileStorage 계정과 Azure File Sync를 사용하여 Azure Files를 통해 온프레미스 Windows Server에 편집 도구 게시

이유: 편집자는 AD를 통한 NTFS ACL 및 ID 기반 인증으로 짧은 지연 시간의 SMB 액세스를 얻고, Azure File Sync는 로컬 캐싱 및 클라우드 계층화를 제공합니다. 프리미엄 계층은 대화형 워크로드에 대해 일관된 성능을 보장합니다.

Azure Front Door로 정적 웹 사이트를 보호하고 캐싱 및 사용자 지정 HTTPS 활성화

이유: 엣지 POP은 전 세계적으로 지연 시간을 줄이고, 사용자 지정 도메인은 브랜딩 요구 사항을 충족하며, WAF는 스토리지 백엔드를 변경하지 않고 보안을 추가합니다.

스토리지 계정 변경 피드를 활성화하고 규정 준수 스토어에 보관

이유: Blob 변경에 대한 불변의 순서가 지정된 로그는 다운스트림 분석, 감사 및 재현 가능한 콘텐츠 파이프라인을 위한 재생을 지원합니다.

← Azure Functions 및 Serverless 컴퓨팅 · 모든 도메인 · Azure Cosmos DB →

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

Pass the whole exam — not just this question

You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.

시험 합격하기 →

Microsoft 찾아보기 →