Practice Test #2

하위 질문 2008에는 답변 가능한 certification 항목이 포함되어 있지 않습니다. 제공된 옵션('Pass'/'Fail')은 보기의 Azure Backup policy와 관련이 없으며 유효한 hotspot 선택에 해당하지 않습니다. 실제 hotspot 프롬프트가 누락되었고 이미지에는 backup policy 구성만 표시되어 있으므로, 이 하위 질문의 정답을 판단하기에 충분한 컨텍스트가 없습니다.

최대 복구 기간은 daily + weekly + monthly를 합산하여 결정되는 것이 아니라, 활성화된 보존 범위 중 가장 긴 보존 기간에 의해 결정됩니다. 정책에서: - Daily recovery points는 90일 동안 보존됩니다. - Weekly recovery points는 26주 동안 보존됩니다. - Monthly recovery points는 36개월 동안 보존됩니다. - Yearly retention은 구성되지 않았습니다. Monthly retention이 36개월로 활성화되어 있으므로, 최대 36개월 전의 recovery point로 복구할 수 있습니다(해당 기간에 대한 monthly recovery point가 있는 경우). 90일 및 26주 설정은 더 최근 기간에 대해 추가 restore points를 제공하지만, 가장 긴 계층을 넘어 최대 기간을 확장하지는 않습니다. 다른 선택지가 틀린 이유: - 90일과 26주는 36개월보다 더 짧습니다. - 45개월은 어디에도 구성되어 있지 않습니다. 이러한 보존 기간은 서로 겹치고 서로 다른 granularity tiers를 나타내며 누적 시간이 아니므로, 36개월 + 26주 + 90일로 더할 수 없습니다.

Recovery Point Objective (RPO)는 시간으로 측정되는 허용 가능한 최대 데이터 손실량이며, Azure VM backups의 경우 이는 주로 백업이 수행되는 빈도(backup schedule frequency)에 의해 결정됩니다. policy는 다음을 보여줍니다: - Frequency: Daily - Time: 오후 6:00 (UTC) 이는 Azure Backup이 하루에 하나의 예약된 recovery point를 생성한다는 의미입니다. 따라서 이 policy로 달성할 수 있는 최소(최상의 경우) RPO는 1일입니다. 왜냐하면 최악의 경우 백업 사이의 변경 사항이 거의 24시간까지 손실될 수 있기 때문입니다. 다른 선택지가 틀린 이유: - 1시간은 daily schedule로는 달성할 수 없습니다(더 빈번한 백업이 필요함). - 1주, 1개월, 1년은 여기서 backup frequency가 아니라 retention/granularity 개념입니다. Weekly/monthly retention은 특정 recovery points를 얼마나 오래 보관하는지를 제어할 뿐, 얼마나 자주 생성되는지를 제어하지 않습니다. - Instant Restore (3일)는 restore 속도/위치에 영향을 주는 것이지 backup frequency에 영향을 주는 것이 아니므로, RPO를 daily보다 더 낮추지 않습니다.

정답: Traffic Manager 프로필. Azure Traffic Manager는 엔드포인트(예: North Europe 및 West Europe의 두 App Service 앱) 전반에 걸쳐 전역 DNS 기반 라우팅을 제공합니다. 엔드포인트 상태를 지속적으로 프로브하며, 사용자를 기본 지역으로 보내고 기본 지역을 사용할 수 없게 되면 자동으로 장애 조치할 수 있습니다. 이는 사용자가 해당 지역에 장애가 발생하지 않는 한 항상 North Europe에 액세스해야 한다는 요구 사항을 직접적으로 충족하며, 지역 가용성을 제공합니다. Azure Application Gateway(B)가 아닌 이유: Application Gateway는 지역별 Layer 7 load balancer입니다. 두 지역을 포괄하려면 일반적으로 지역마다 하나씩 배포한 다음, 여전히 지역 간 선택을 위한 전역 라우팅 메커니즘(보통 Traffic Manager 또는 Front Door)이 필요합니다. 이는 요구 사항을 충족하는 데 필요한 것보다 더 많은 비용과 복잡성을 추가합니다. Azure Load Balancer(C)가 아닌 이유: Azure Load Balancer는 지역별 Layer 4이며 App Service 엔드포인트에 대해 지역 간 DNS 기반 장애 조치를 제공할 수 없습니다. 전역/지역 장애 조치 라우팅에 적합한 도구가 아닙니다.

정답: Priority 트래픽 라우팅. Traffic Manager의 Priority 라우팅은 active/passive 설계를 위해 특별히 사용됩니다. North Europe endpoint를 가장 높은 우선순위(가장 낮은 priority number)로 구성하고, West Europe endpoint를 그다음 우선순위로 구성합니다. Traffic Manager는 North Europe이 정상 상태인 동안 모든 사용자를 North Europe으로 보내고, North Europe이 health probe에 실패할 때만 West Europe으로 라우팅합니다. Performance 라우팅(B)이 아닌 이유: Performance 라우팅은 각 사용자에게 가장 낮은 network latency를 가진 endpoint를 선택하므로, North Europe이 정상이어도 일부 사용자를 West Europe으로 보낼 수 있어 요구 사항을 위반합니다. Weighted 라우팅(D)이 아닌 이유: Weighted 라우팅은 가중치에 따라 endpoint 간에 트래픽을 분산(active/active)하므로, 정상 운영 중에도 일부 트래픽을 West Europe으로 보내게 됩니다. Cookie 기반 session affinity(A)가 아닌 이유: 이것은 sticky session을 위한 Application Gateway 기능이지 Traffic Manager 라우팅 방식이 아니며, regional failover 선호를 해결하지도 않습니다.

정답이 적절합니다. 올바른 설계는 일반적인 AZ-305 identity + API protection 패턴이기 때문입니다. 즉, Azure AD에서 authorize하고 API Management에서 JWT validation을 사용해 적용합니다. 요구 사항에는 Azure AD에서 생성된 claims를 사용하고 configuration/management를 최소화해야 한다고 명시되어 있습니다. 이는 20개의 각 API 내부에 authorization을 구현하는 방식(더 많은 노력 필요)보다는 APIM policies에서 중앙 집중식으로 적용하는 방식을 가리킵니다. 따라서 솔루션은 다음과 같습니다. 웹 앱이 API를 호출할 수 있도록 Azure AD permissions(scopes/app roles)을 구성하고, APIM이 JWT와 필요한 claims를 validate하도록 구성합니다. 이렇게 하면 unauthorized requests가 API에 도달하기 전에 gateway에서 차단됩니다.

웹 앱이 웹 API에 액세스할 수 있도록 권한을 부여하는 작업은 Azure AD (Microsoft Entra ID)에서 app registrations를 통해 수행됩니다. 방법은 다음 중 하나입니다: - API app registration에서 API를 노출하고(OAuth2 scopes 정의) 웹 앱에 delegated/application permissions를 부여하거나, - API에 app roles를 정의하고 이를 호출하는 웹 앱/service principal에 할당합니다. 이곳이 consent 및 permission grants가 관리되는 권한 있는 위치이며, Azure AD가 관련 claims(예: scopes의 경우 scp, app roles의 경우 roles)를 포함하는 tokens를 발급하는 곳입니다. 왜 APIM이 아닌가요? APIM은 tokens를 적용할 수는 있지만 Azure AD permissions를 정의하거나 부여하지는 않으며, Azure AD와 통합됩니다. 왜 “웹 API”가 아닌가요? 각 API에 직접 permissions를 구현하면 관리 노력이 증가하고 Azure AD가 발급한 tokens에 대한 중앙 권한 부여 메커니즘이 되지 않습니다.

Azure API Management에서 JWT 유효성 검사를 구성합니다. APIM은 다음을 검증하기 위한 기본 제공 validate-jwt 정책을 제공합니다: - Token signature (Azure AD OpenID metadata 사용) - Issuer (iss) - Audience (aud) - Token lifetime - scopes (scp) 또는 roles (roles)와 같은 필수 claims 이는 APIM이 gateway 계층에서 유효하지 않거나 권한이 없는 호출을 거부하기 때문에 “권한이 없는 요청이 웹 APIs에 도달하지 못하도록 차단” 요구 사항을 직접 충족합니다. 왜 Azure AD가 아닌가요? Azure AD는 tokens를 발급하고 권한을 정의하지만, 모든 API 요청을 검증하기 위해 inline으로 위치하지는 않습니다. resource server/gateway가 JWT를 검증해야 합니다. 왜 “웹 APIs”가 아닌가요? 각 API에서 JWT를 검증할 수는 있지만, 그렇게 하면 20개의 APIs 전반에 걸쳐 구성과 지속적인 관리가 증가하여 노력을 최소화해야 한다는 요구 사항을 위반합니다. APIM에서 중앙 집중화하는 것이 의도된 설계입니다.