Practice Test #5

Set-variable는 Inbound 섹션에 배치해야 합니다. 캐싱 결정이 이루어지기 전에 요청 범위 데이터(감지된 사용자 identity)를 도출하고 유지해야 하기 때문입니다. Inbound는 APIM이 들어오는 요청 헤더(Authorization: Bearer <JWT> 포함)에 접근할 수 있고, JWT claims(예: sub, oid, upn)를 파싱하여 안정적인 사용자 식별자를 계산할 수 있는 위치입니다. Inbound에서 사용자 ID를 변수에 저장하면, 이후의 Inbound policies(예: cache-lookup-value)가 "{location}:{userId}"와 같은 cache key를 구성할 수 있습니다. 이를 Outbound까지 기다리면 이미 backend를 호출한 뒤이므로, backend 호출을 피하기 위해 cache를 사용하는 목적을 달성할 수 없습니다. Outbound는 주로 응답 변환과 후처리를 위한 것이며, 요청 기반 routing/caching 결정을 위한 곳이 아닙니다.

Cache-lookup-value는 backend로 request를 전달하기 전에 cache를 확인하는 것이 목적이므로 Inbound section에 속합니다. cache-lookup-value가 항목을 찾으면 APIM은 cached payload를 즉시 반환하고 backend 호출을 건너뛸 수 있으며, 이것이 gateway caching의 주요 성능 이점입니다. cache lookup을 outbound에 배치하면 너무 늦습니다. backend가 이미 호출된 후이므로 backend load나 latency를 줄일 수 없습니다. Inbound lookup은 또한 request context(location parameter/path + JWT에서 추출한 user ID variable)로부터 cache key를 구성할 수 있도록 보장합니다. 이것은 보안 측면에서도 중요합니다. 사용자별 caching은 어떤 response도 생성되기 전에 적용되어야 하며, 그래야 사용자 간 response가 섞이는 것을 방지할 수 있습니다.

Cache-store-value는 Outbound 섹션에 배치해야 합니다. 일반적으로 backend가 응답을 생성한 후(그리고 캐시된 콘텐츠에 반영되어야 하는 outbound 변환 이후)에 응답을 캐시하려고 하기 때문입니다. Outbound는 client에 반환될 최종 응답 body/status/headers를 캡처하는 올바른 단계입니다. Inbound에 저장하면 아직 캐시할 backend 응답이 없습니다. 또한 outbound 수정 후 캐싱하면 일관성이 보장됩니다. 즉, 캐시된 표현이 client가 실제로 받는 내용과 일치합니다(예: user profile 정보를 주입하거나 필드를 정규화한 후). 이 접근 방식은 동일한 user/location 조합에 대해 반복적인 backend 호출을 줄여 Performance Efficiency pillar를 지원합니다.

Find-and-replace는 response body transformation policy이므로 Outbound 섹션에 적용해야 합니다. 요구 사항에서 user profile information으로 response body를 업데이트하라고 명시하고 있으며, 이는 response가 존재한 후에만 가능하고 의미가 있습니다. Inbound policies는 request가 backend로 전송되기 전에 request에 대해 동작하므로 response body를 수정하기에 적절한 위치가 아닙니다. Outbound에서는 APIM이 response payload를 읽고 다시 쓸 수 있습니다(예: placeholder token을 user-specific profile data로 교체). 또한 이를 outbound에서 수행하면 cache-store-value를 통해 캐시하는 내용에 transformed content를 포함할 수 있으므로, 동일한 user/location에 대한 후속 요청은 backend logic을 다시 실행하지 않고 entirely from cache로 제공될 수 있습니다.

예. 들어오는 요청을 검사하는 policy(예: 요청 본문 크기 확인)와 요청 URL을 다시 쓰거나 정규화하는 policy(예: 특정 API version 세그먼트 유지)는 요청이 backend로 전송되기 전에 적용됩니다. 이것이 바로 <inbound> 섹션의 용도입니다. APIM에서 <inbound>는 요청 유효성 검사, header/query/path 조작, 그리고 routing 결정에 적합한 위치입니다. 반면 <outbound>는 backend에서 돌아오는 응답을 변환하는 데 사용되며, <backend>는 APIM이 요청을 어떻게 전달할지 구성하는 데 사용됩니다(예: set-backend-service). 일반적으로 요청 payload 크기를 검증하는 용도로는 사용되지 않습니다. <on-error>는 오류가 발생한 후에만 실행됩니다. 따라서 요청 본문 크기를 평가하고/하거나 요청 path를 다시 쓰는 XML 세그먼트는 <inbound>에 속합니다.

아니요. 256 KB를 초과하는 body size가 정책이 해당 제한을 명시적으로 적용하지 않는 한 자동으로 오류를 발생시키지는 않습니다(예: max-size와 함께 validate-content를 사용하거나, size가 임계값을 초과할 때 오류 응답을 반환하는 choose/when 사용). APIM에는 request body를 읽거나 buffering할 때의 실질적인 제한과 고려 사항이 있지만, 단순히 "bodySize"와 같은 변수를 참조하는 것(코드 조각에서 암시된 것처럼) 자체가 256 KB에서 오류를 발생시키지는 않습니다. 오류는 구성된 제한을 초과하는 body를 읽으려고 시도할 때, buffering이 필요하지만 불가능할 때, 또는 validation policy가 request를 거부하도록 구성된 경우에 발생합니다. 시험에서는 (a) 계산된 값/변수와 (b) 적용 정책을 구분하세요. 256 KB에 연결된 명시적인 reject/return-response/validate-content 규칙이 없다면, 256 KB를 초과하는 것만으로는 오류가 발생한다고 보장되지 않습니다.

예. http://contoso.com/api/9.2/와 같은 요청에서, 버전을 비교하고 더 높은 버전을 유지하도록 설계된 policy는 더 낮은 버전(예: 9.1 또는 9.0)과 비교할 때 9.2를 유지합니다. 이는 일반적인 APIM 패턴입니다. 즉, path에서 버전 세그먼트를 추출하고, 이를 구성되었거나 예상된 버전과 비교한 다음, 그에 따라 rewrite 또는 route합니다. APIM policy expressions에서는 버전을 비교하는 방식에 주의해야 합니다. policy가 숫자/semantic parsing을 사용하는 경우(예: Version type으로 변환하거나 major/minor 정수로 분리), 9.2는 9.1보다 더 높은 버전으로 올바르게 평가됩니다. 문자열을 단순 비교하는 방식을 사용하면 일부 경우 결과가 잘못될 수 있습니다(예: "9.10"과 "9.2"). 그러나 이 문장은 특히 9.2에 대해 policy가 더 높은 버전을 유지한다고 말하고 있으며, 이는 이러한 policy의 의도된 동작과 일치합니다. 따라서 주어진 시나리오에서 policy는 더 높은 버전을 유지하며, 9.2가 유지됩니다.