Practice Test #1

정답: C (getContext().getRequest();). Cosmos DB JavaScript trigger에서는 request object를 통해 현재 작업(create/replace)에 접근합니다. pre-trigger의 경우, request.getBody() 및 request.setBody()를 사용하여 기록될 document를 읽고 수정합니다. 이것이 write가 커밋되기 전에 tip property가 존재하고 numeric인지 확인하는 데 정확히 필요한 방식입니다. 다른 선택지가 틀린 이유: - A (__.value();)는 Cosmos DB trigger API 호출이 아닙니다. - B (__.readDocument('item');)는 들어오는 document를 수정하는 trigger에 적절한 패턴이 아닙니다. 기존 document를 읽는 것은 stored procedure에서 더 일반적이거나 관련 데이터를 가져와야 할 때 사용되며, 제시된 선택지는 표준 trigger 호출 시그니처가 아닙니다. - D (getContext().getResponse();)는 주로 작업 후 response를 구성하기 위한 post-trigger에서 사용되며, persistence 전에 필수 property를 강제하는 용도가 아닙니다.

trigger는 tip 속성이 존재하고 숫자 값을 포함하는지 확인해야 합니다. Option C는 tip이 숫자가 아니거나 null인지 올바르게 확인하며, 이는 유효하지 않은 값을 처리하고 trigger가 0과 같은 기본 숫자 값을 할당할 수 있게 합니다. Option A는 속성이 누락되었는지만 확인하며 tip이 존재하지만 숫자가 아닌 경우를 처리하지 못하므로 요구 사항을 충족하지 않습니다. Options B와 D는 이 시나리오의 Cosmos DB JavaScript triggers에서 유효하지 않은 API 또는 패턴을 사용합니다.

정답: A (setBody(i);). pre-trigger에서는 들어오는 document를 수정한 후(예: i.tip이 없을 때 i.tip = 0 추가), request.setBody(i)를 사용하여 업데이트된 document를 request pipeline에 다시 써야 합니다. 이렇게 해야 Cosmos DB가 수정된 버전의 document를 저장합니다. 다른 선택지가 틀린 이유: - B (setValue(i);)는 request body를 업데이트하기 위한 Cosmos DB trigger method가 아닙니다. - C (upsertDocument(i);)와 D (replaceDocument(i);)는 일반적으로 stored procedure에서 사용되는 document write operation이며(때로는 trigger에서 side effect 용도로도 사용됨), 현재 생성/교체 중인 document를 수정하는 올바른 메커니즘이 아닙니다. 이를 사용하면 의도하지 않은 추가 write, RU consumption, 그리고 잠재적인 recursion/complexity를 유발할 수도 있습니다. 들어오는 document의 field를 강제/정규화하기 위한 시험에서 기대하는 패턴은 request.setBody()입니다.

Azure Function 코드는 KEDA CRD에 속하지 않습니다. KEDA CRD(예: ScaledObject, ScaledJob, TriggerAuthentication, ClusterTriggerAuthentication)는 autoscaling 규칙과 authentication 메커니즘을 설명하며, application 코드는 설명하지 않습니다. Azure Function을 Kubernetes로 마이그레이션할 때 function 코드는 container image(Functions runtime 및 function binaries 포함)로 패키징되고, Deployment(또는 패턴에 따라 Job/CronJob 가능)와 같은 표준 Kubernetes 리소스를 사용하여 배포됩니다. 그런 다음 KEDA는 해당 Deployment를 대상으로 scale합니다. 따라서 질문이 “Azure Function 코드는 어떤 CRD 유형에 속하는가”를 묻는 것이라면, 올바른 해석은 그것이 KEDA CRD에 전혀 속하지 않는다는 것입니다. 그것은 container image와 Kubernetes workload 리소스에 속합니다. 이것은 흔한 시험 함정입니다: KEDA는 autoscaler이지 application packaging 메커니즘이 아닙니다.

Polling interval은 KEDA ScaledObject(또는 ScaledJob) CRD에서 구성됩니다. Azure Storage Queues와 같은 event source의 경우, KEDA는 external system에 metric(예: queue length)을 조회하기 위해 polling loop를 사용합니다. pollingInterval 설정은 KEDA가 trigger source를 얼마나 자주 확인하는지를 제어합니다. 이는 responsiveness와 external system의 cost/load에 직접적인 영향을 줍니다. KEDA에서 ScaledObject는 scale target(예: Deployment)을 하나 이상의 trigger에 바인딩하고 pollingInterval, cooldownPeriod, minReplicaCount, maxReplicaCount와 같은 scaling 관련 parameter를 포함하는 CRD입니다. TriggerAuthentication은 credentials/auth configuration을 제공하기 위한 용도일 뿐이며 polling behavior를 정의하지 않습니다. 따라서 polling interval은 ScaledObject configuration에 속합니다.

Azure Storage connection string은 KEDA authentication configuration을 통해 처리되며, 일반적으로 Kubernetes Secret을 참조하는 TriggerAuthentication(또는 ClusterTriggerAuthentication)을 사용합니다. KEDA trigger는 Azure Storage에 액세스하기 위해 connection information이 필요하지만, best practice는 secret을 ScaledObject manifest에 직접 포함하지 않는 것입니다. 대신 connection string을 Kubernetes Secret에 저장한 다음, 해당 secret을 참조하도록 TriggerAuthentication을 구성합니다(예: secretTargetRef). 그런 다음 ScaledObject trigger가 authentication object를 참조합니다. 이 접근 방식은 security best practice 및 Azure Well-Architected Framework(비밀 보호, credential rotation, 최소 노출)에 부합합니다. 많은 KEDA의 Azure Storage Queue 예제에서 trigger metadata에는 queueName이 포함되고, credential은 TriggerAuthentication을 통해 제공됩니다. 따라서 connection string은 scaling rule 자체가 아니라 authentication CRD 경로에 속합니다.

정답 indexing policy는 "compositeIndexes" 속성을 사용합니다. Cosmos DB는 여러 필드에 대한 ORDER BY에 composite index를 요구하기 때문입니다. 이 query는 기본적으로 p.name을 ascending으로, 그리고 p.city를 명시적으로 descending으로 정렬하므로, composite index는 정확히 그 순서대로 [{"path":"/name","order":"ascending"},{"path":"/city","order":"descending"}]여야 합니다. 현재 이미지는 /name을 descending으로 표시하고 있으며, 이는 작성된 query를 지원하지 않습니다. "orderBy" 및 "sortOrder" 같은 옵션은 Cosmos DB에서 유효한 indexing policy 속성 이름이 아닙니다.

Bounded staleness는 시간 기반 허용 오차 윈도우를 명시적으로 지원하면서도 ordering guarantees를 유지하는 유일한 옵션입니다. Bounded staleness에서는 reads가 writes보다 최대 K versions 또는 T 시간(여기서는 5초)만큼 뒤처질 수 있지만, clients는 out-of-order updates를 절대 보지 않습니다(consisent prefix와 bounded lag를 함께 제공합니다). 이는 최대 5초의 허용 오차 윈도우를 허용하면서 예약을 순서대로 처리해야 한다는 요구 사항과 일치합니다. Strong consistency (A)는 가장 엄격한 ordering/linearizability를 제공하지만, 일반적으로 replicas 간 coordination/quorum이 필요하므로 multi-region 시나리오에서 latency를 증가시키고 availability를 낮출 수 있습니다. 또한 명시된 허용 오차 윈도우와도 맞지 않습니다(필요 이상으로 엄격함). Consistent prefix (C)는 순서를 보존하지만 staleness를 제한하지 않으므로 “최대 5초” 요구 사항을 보장할 수 없습니다. Eventual consistency (B)는 가장 약한 guarantees를 제공하며 out-of-order results를 반환할 수 있어 overbooking 위험이 있고 sequencing 요구 사항을 위반합니다.

요구 사항은 SQL API Cosmos DB account를 프로비저닝하라고 명시적으로 말하며, Azure CLI에서는 --kind 'GlobalDocumentDB'로 생성합니다. 이 옵션은 Core (SQL) API account 유형을 선택합니다. --enable-automatic-failover true는 복원력을 향상시키지만 API kind를 지정하지 않으므로 이 빈칸에는 맞지 않습니다. --kind 'MongoDB'는 잘못된 API이며, virtual network 활성화는 account 유형 요구 사항과 관련이 없습니다.

99.99% 가용성을 달성하고 지역화된 장애를 허용하려면 Cosmos DB account를 여러 region에 배포해야 합니다. --locations ‘southcentralus=0 eastus=1 westus=2’ 옵션은 명시적인 failover priority(0이 가장 높은 priority)와 함께 multi-region replication을 구성합니다. 이는 낮은 latency(구성에 따라 client가 더 가까운 region에서 읽을 수 있음)와 높은 가용성(service가 region을 사용할 수 없을 때 fail over 가능)을 지원합니다. Option D (--locations ‘southcentralus=0’)는 single-region이며 일반적으로 multi-region 구성과 관련된 99.99% 가용성 기대치를 충족하지 못하고, “지역화된 network outage가 발생하더라도 reservation을 수락”해야 한다는 요구 사항도 충분히 강력하게 만족하지 못합니다. Options A와 B는 failover priority 없이 하나의 region만 지정하며 multi-region footprint를 설정하지 않습니다. bounded staleness (max interval 5) 및 automatic failover와 함께 사용할 때, multi-region locations가 latency를 낮게 유지하면서 reliability 및 availability 요구 사항을 가장 잘 충족합니다.