MicrosoftMicrosoft Azure Solutions Architect Expert AZ-305 Certification·KO·업데이트됨 11 Aug 2026
귀사는 두 가지 계층의 공개 API를 제공합니다. Starter(클라이언트당 하루 1,000회 호출)와 Enterprise(클라이언트당 하루 10,000회 호출)입니다. 개발자는 승인 대기 중인 키를 얻기 위해 셀프 서비스로 가입해야 합니다. 각 요청은 자동으로 상관 관계 ID 헤더를 받아야 합니다. 최소한의 오버헤드로 이러한 요구 사항을 충족하는 Azure API Management 구성은 무엇입니까?
정답 선택
옵션을 탭하여 정답을 확인하세요.
정답: 두 가지 제품(Starter, Enterprise)을 정의하고 구독을 요구합니다. 제품 범위에서 적절한 할당량으로 rate-limit-by-key 정책을 연결합니다. 승인이 필요한 셀프 서비스 가입으로 개발자 포털을 활성화합니다. 상관 관계 ID를 삽입하기 위해 API 범위에서 set-header 정책을 추가합니다..
이것이 정답인 이유
이 솔루션은 Azure API Management의 핵심 기능을 활용하여 모든 요구 사항을 충족합니다. '제품'은 Starter 및 Enterprise 계층을 정의하고, '구독'은 클라이언트당 할당량 관리를 가능하게 합니다. 'rate-limit-by-key' 정책은 각 제품에 대한 일일 호출 제한을 적용합니다. '개발자 포털'은 셀프 서비스 가입과 승인 워크플로우를 제공합니다. 마지막으로, 'set-header' 정책은 모든 API 요청에 상관 관계 ID를 자동으로 추가합니다.
다른 옵션들은 다음과 같은 이유로 적절하지 않습니다.
Azure Front Door는 WAF 속도 제한을 제공하지만, 클라이언트별 할당량 관리나 셀프 서비스 가입 워크플로우를 직접 지원하지 않습니다.
두 개의 APIM 인스턴스를 배포하는 것은 불필요하게 복잡하고 비용이 많이 듭니다.
Azure Functions Proxies는 스로틀링을 코드로 구현해야 하므로 관리 오버헤드가 증가합니다.
JWT-validate 정책은 인증에 사용되며, Redis를 통한 수동 스로틀링 구현은 복잡하고 비효율적입니다.