CloudPass LogoCloud Pass
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
Certifications
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
Google Professional Cloud Developer
Google Professional Cloud Developer

Practice Test #1

50개 문제와 120분 시간 제한으로 실제 시험을 시뮬레이션하세요. AI 검증 답안과 상세 해설로 학습하세요.

50문제120분700/1000합격 점수
기출 문제 보기

AI 기반

3중 AI 검증 답안 및 해설

모든 답안은 3개의 최고 AI 모델로 교차 검증하여 최고의 정확도를 보장합니다. 선택지별 상세 해설과 심층 문제 분석을 제공합니다.

GPT Pro
Claude Opus
Gemini Pro
선택지별 상세 해설
심층 문제 분석
3개 모델 합의 정확도

기출 문제

1
문제 1

You are designing a tablet app for municipal tree inspectors that must store hierarchical observations (city -> district -> park -> tree -> inspection) with up to 5 nested levels and support offline work for up to 72 hours; upon reconnect, the app must automatically sync local changes and handle conflicts gracefully. A backend on Cloud Run will use a dedicated service account to enrich the same records (e.g., geocoding, policy tags) directly in the database, performing up to 5,000 writes per minute at peak. The solution must scale securely to 250,000 monthly active users in the first quarter and provide client SDKs with built-in offline caching and synchronization. Which database and IAM role should you assign to the backend service account?

Cloud SQL은 계층 구조에 대한 relational modeling을 지원하지만, 모바일/tablet apps를 위한 내장 offline persistence 및 automatic sync를 제공하는 Google client SDKs가 없습니다. local storage, change tracking, conflict resolution, sync logic을 직접 구현해야 합니다. 또한 roles/cloudsql.editor는 database-level DML permissions를 직접 부여하는 것이 아니라 instance를 관리하는 권한이며, app-level writes에 필요한 것보다 더 광범위합니다.

Bigtable은 높은 write throughput과 대규모 scale을 처리할 수 있지만, 계층형 document 탐색과 offline-first 모바일 sync보다는 time-series/analytics 스타일 access pattern에 최적화된 wide-column store입니다. offline caching/synchronization을 위한 Firestore 같은 client SDKs가 없습니다. 또한 roles/bigtable.viewer는 read-only이므로 backend가 records를 write로 enrichment해야 하는 요구사항을 충족할 수 없습니다.

Firestore in Native mode는 Firebase/Firestore client SDKs(offline persistence, local cache, reconnect 시 automatic sync)를 통해 계층형 관측 데이터와 offline-first 운영 요구사항을 충족합니다. hot spots를 피하도록 설계하면 대규모 user base로 확장 가능하며 높은 write rate도 지원합니다. roles/datastore.user는 backend service account에 Firestore에 대한 필요한 read/write access를 제공하여 enrichment updates를 안전하게 수행할 수 있게 합니다.

Firestore in Datastore mode는 주로 Datastore API compatibility를 위한 것이며, client apps에 대한 Firebase 스타일 offline synchronization 기대치와 직접적으로 잘 맞지 않습니다. 설령 database 선택이 수용 가능하더라도 roles/datastore.viewer는 read-only이므로 Cloud Run backend가 records를 enrichment하기 위해 분당 최대 5,000 writes를 수행해야 하는 요구사항을 충족할 수 없습니다.

문제 분석

핵심 개념: 이 문제는 계층형 데이터 모델링을 지원하면서 Google 제공 client SDK를 통해 모바일/오프라인-퍼스트 동기화를 지원하는 database를 선택하고, 해당 database에 write해야 하는 Cloud Run service account에 대해 최소 권한 IAM role을 고르는지를 평가합니다. 정답이 맞는 이유: Firestore in Native mode가 가장 적합합니다. Firebase/Firestore client SDK의 기반이 되는 database로서, 내장 offline persistence, local caching, 그리고 연결이 복구되면 자동 synchronization을 제공하므로 72시간 오프라인 요구사항과 “sync + conflict handling” 요구사항에 정확히 부합합니다. Firestore의 document/collection 모델은 subcollections를 사용하거나 reference/ID를 저장하는 방식으로 계층형 entity(도시/구/공원/나무/점검)를 자연스럽게 표현할 수 있으며, subcollections는 최대 100 레벨까지 지원하므로 5단계 중첩은 제한 내에 충분히 들어옵니다. Cloud Run에서 backend enrichment를 수행하려면 service account에 Firestore에 대한 read/write access가 필요하며, roles/datastore.user는 entity/document를 read 및 write할 수 있는 권한을 부여합니다(서버 사이드 access의 일반적인 최소 권한 기준). 이를 통해 backend가 분당 최대 5,000 writes를 수행할 수 있습니다. 주요 기능 및 best practices: - Offline-first: Firestore SDKs(Android/iOS/Web)는 offline persistence와 automatic sync를 지원합니다. conflict는 보통 “last write wins” semantics로 처리되며, transactions, server timestamps, custom merge logic로 개선할 수 있습니다. - Scale: Firestore는 serverless이며 높은 concurrency와 대규모 user base를 위해 설계되었습니다. Google Cloud Architecture Framework의 scalability 및 operational excellence 원칙과도 부합합니다. - Security: end-user auth에는 Firebase Authentication/Identity Platform을 사용하고, client access에는 Firestore Security Rules를 사용합니다. Cloud Run에는 IAM 기반 access를 가진 전용 service account를 사용합니다. - Throughput: 분당 5,000 writes(초당 약 83 writes)는 일반적으로 가능하며, hot-spot 회피(문서 key 전반에 write 분산, 단일 문서 contention 회피) 관점에서 설계해야 합니다. 흔한 오해: - Cloud SQL은 계층형 데이터를 저장할 수 있지만 offline sync SDK를 제공하지 않습니다. custom sync/conflict resolution을 직접 구축해야 합니다. - Bigtable은 매우 scalable하지만 모바일 offline sync SDK가 없고 계층형 document access pattern에 이상적이지 않습니다. - Firestore in Datastore mode는 Datastore APIs에 더 초점이 맞춰져 있어 Firebase offline sync 기대치와 직접적으로 잘 맞지 않습니다. Exam tips: “offline caching과 automatic synchronization이 있는 client SDKs”를 보면 Firestore (Native mode) / Firebase를 떠올리세요. 그다음 backend service account에 필요한 작업(read/write)을 가능하게 하는 IAM role을 선택합니다. viewer role은 write에 사용할 수 없고, 과도하게 광범위한 role은 피해야 합니다.

2
문제 2

Your team uses Cloud Build to run CI for a Go microservice stored in a private GitHub repository mirrored to Cloud Source Repositories; one of the build steps requires a specific static analysis tool (version 3.7.2) that is not present in the default Cloud Build environment, the tool is ~120 MB and must be available within 5 seconds at step start to keep total build time under a 10-minute SLA, outbound internet access during builds is restricted, and you need reproducible results across ~50 builds per day—what should you do?

빌드 중 바이너리를 다운로드하는 방식은 취약하며 제시된 제약을 대체로 충족하지 못합니다. 아웃바운드 인터넷 접근이 제한되어 다운로드가 완전히 차단될 수 있습니다. 허용되더라도 네트워크 변동성과 업스트림 가용성 문제로 5초 시작 요구사항을 쉽게 초과하고 10분 SLA를 위협할 수 있습니다. 또한 체크섬을 고정하고 미러를 처리하지 않으면 재현성이 떨어지며, 이는 복잡성과 리스크를 추가합니다.

커스텀 Cloud Build builder 이미지가 가장 적합합니다. 정확한 도구 버전(3.7.2)을 컨테이너 이미지에 패키징하여 단계가 시작되는 즉시 사용할 수 있게 합니다. 이는 아웃바운드 인터넷 접근을 피하고, 성능을 개선하며(런타임 다운로드 없음), 이미지 태그 또는 더 나은 방식으로 이미지 digest를 고정하여 재현 가능한 결과를 보장합니다. 이미지를 Artifact Registry에 저장하면 통제되고 감사 가능한 CI 의존성을 지원합니다.

120 MB 바이너리를 소스 리포지토리에 커밋하면 인터넷 없이도 빌드가 가능해질 수 있지만, CI/CD 관점에서 좋지 않은 관행입니다. 리포지토리를 비대하게 만들고, 클론 및 미러링을 느리게 하며, 코드 리뷰를 복잡하게 하고, 공급망 거버넌스 문제(바이너리 출처, 스캐닝, 라이선스)를 만들 수 있습니다. 또한 도구 배포를 소스 변경에 결합시키며, 여러 서비스나 파이프라인이 동일 도구를 필요로 할 때 오류가 발생하기 쉽습니다.

기능 요청을 제출하는 것은 즉각적인 요구사항을 해결하지 못하며 SLA를 충족하기 위한 신뢰할 수 있는 전략이 아닙니다. 기본 Cloud Build 환경은 Google의 일정에 따라 변경되며, 특수한 도구나 특정 버전을 포함하지 않을 수 있습니다. 추가되더라도 재현성을 위해 버전 고정이 필요합니다. 시험에서는 명확한 제약이 있을 때 “플랫폼이 추가해주길 기다린다”는 거의 정답이 아닙니다.

문제 분석

핵심 개념: 이 문제는 Cloud Build 실행 환경과 빌드 단계에 대해 결정적(deterministic)이고 빠르며 오프라인인 의존성을 제공하는 방법을 테스트합니다. Cloud Build에서는 각 단계가 컨테이너 이미지에서 실행됩니다. 필요한 도구가 기본 builders에 없다면, 빌드 시점에 가져오거나(custom download) 커스텀 builder 이미지에 패키징할 수 있습니다. 정답이 맞는 이유: 정적 분석 도구(v3.7.2)가 이미 포함된 커스텀 Cloud Build builder 이미지는 단계가 시작되자마자 도구를 즉시 사용할 수 있게 해주어(5초 요구사항 충족) 외부 인터넷 아웃바운드 접근을 피할 수 있습니다(제한됨). 또한 도구 버전이 이미지에 고정(pinned)되므로 하루 약 50회 빌드 전반에서 재현성을 보장합니다. 이는 CI 모범 사례(불변(immutable)이고 버전 관리되는 빌드 환경으로 변동성과 외부 의존성을 줄임)와 일치합니다. 주요 기능 / 구성 / 모범 사례: - 커스텀 builder 이미지(예: 최소 Linux 이미지 또는 공식 Go builder 기반)를 만들고 120 MB 바이너리를 이미지 레이어에 포함(bake)합니다. - 이미지를 Artifact Registry(또는 Container Registry)에 저장하고 cloudbuild.yaml 단계에서 이미지 이름으로 참조합니다. - 최대 재현성을 위해 불변 digest(예: image@sha256:...)로 고정(pin)합니다. - 더 엄격한 네트워크 egress 제어가 필요하면 Cloud Build private pools를 사용합니다. 다만 egress가 제한되더라도, 사전 패키징된 이미지는 런타임 다운로드를 피할 수 있습니다. - 이 접근은 Google Cloud Architecture Framework 원칙을 지원합니다: 신뢰성(일관된 빌드), 운영 우수성(반복 가능한 파이프라인), 성능 효율성(빠른 단계 시작). 흔한 오해: 빌드 중 다운로드(옵션 A)는 단순해 보이지만, 제한된 아웃바운드 인터넷 요구사항을 위반하고 지연/가용성 리스크를 유발하여 10분 SLA를 깨뜨릴 수 있습니다. 바이너리를 커밋(옵션 C)하는 방식은 재현 가능해 보일 수 있지만, 리포지토리를 비대하게 만들고 리뷰를 복잡하게 하며, 일반적으로 공급망(supply-chain) 및 유지보수 관점에서 안티 패턴입니다. 기본 지원 요청(옵션 D)은 시험 시나리오에서 실행 가능한 해결책이 아니며 즉각적인 SLA 요구를 충족하지 못합니다. 시험 팁: Cloud Build 문제에서 “도구가 없음”, “인터넷 없음”, “빠른 시작”, “재현 가능한 빌드”가 나오면 기대되는 패턴은 다음입니다: 커스텀 builder 이미지를 만들고, Artifact Registry에 저장한 뒤, 빌드 단계에서(종종 digest로 고정하여) 참조합니다. 런타임 다운로드나 대용량 바이너리를 소스 컨트롤에 커밋하는 것보다 불변이고 버전 관리되는 아티팩트를 선호하세요.

3
문제 3

You are building an external review portal for a film festival that stores high‑bitrate video dailies in Cloud Storage, and you must let reviewers—some of whom do not have Google accounts—securely access only their assigned files with the ability to read, upload replacements, or delete them for a strict 24-hour window; how should you provide access to the objects?

정답입니다. V4 signed URL을 사용하면 검토자가 Google account로 인증할 필요 없이 애플리케이션이 특정 Cloud Storage object에 대한 임시 액세스를 부여할 수 있습니다. 이는 외부 사용자에 대한 요구 사항과 일치하며, 할당된 파일에 대해서만 URL을 생성함으로써 최소 권한 액세스를 지원합니다. 24시간 만료도 지원되므로, 이 시나리오에서 안전하고 시간 제한이 있는 object 액세스를 위한 가장 적합한 방법은 signed URL입니다.

오답입니다. Service Account Token Creator를 부여하면 impersonation이 가능해지며, 이는 외부 사용자에게는 강력하고 위험합니다. 권한 구성에 따라 검토자가 credential을 획득하고 할당된 객체를 넘어서는 액세스를 할 수 있는 경로를 사실상 제공할 수 있습니다. 또한 검토자가 Google IAM 기반 flow와 identity를 사용할 수 있다는 전제를 깔고 있어 “일부는 Google account가 없다”는 조건과 충돌하며, 최소 권한에도 부합하지 않습니다.

오답입니다. 외부 검토자에게 service account key를 배포하는 것은 중대한 보안 anti-pattern입니다. 키는 복사, 재사용, 유출(exfiltration)될 수 있습니다. 또한 service account key는 암시된 것처럼 “24시간 후 만료”를 기본적으로 지원하지 않으며, 키를 수동으로 rotation/delete해야 합니다. 이 접근은 광범위한 액세스를 부여하고 credential management 모범 사례를 위반합니다.

오답입니다. IAM role(만료되는 IAM Conditions가 있더라도)은 principal identity에 대한 binding이 필요합니다. Google account가 없는 검토자에게는 bucket에 Storage Object User를 직접 부여할 수 없습니다. 또한 bucket 수준 role 할당은 복잡한 conditional logic을 결합하지 않는 한 객체별 액세스보다 범위가 넓습니다. signed URLs가 객체 수준의 시간 제한 외부 액세스에 더 단순하고 정밀합니다.

문제 분석

핵심 개념: 이 문제는 Google identity가 없을 수 있는 외부 사용자에게 Cloud Storage object에 대한 안전한 시간 제한 액세스를 제공하는 방법을 테스트합니다. 핵심 개념은 Cloud Storage signed URL을 사용하여 최종 사용자에게 직접 IAM permission을 부여하지 않고도 특정 object에 대한 임시 액세스를 위임하는 것입니다. 정답인 이유: 일부 검토자는 Google account가 없으므로 IAM role binding은 적절한 방법이 아닙니다. Signed URL을 사용하면 애플리케이션이 제한된 시간 동안 개별 object에 대한 액세스를 부여할 수 있으며, 이는 각 검토자가 24시간 동안 자신에게 할당된 파일에만 액세스하도록 제한해야 한다는 요구 사항과 일치합니다. 이것은 Cloud Storage object에 대한 임시 외부 액세스를 위한 표준 Google Cloud 패턴입니다. 주요 기능 / 모범 사례: - Google authentication을 요구하지 않고 임시 object 액세스를 제공하기 위해 24시간 만료의 V4 signed URL을 사용합니다. - Object별로 URL을 생성하여 각 검토자가 자신에게 할당된 파일에만 액세스할 수 있도록 합니다. - Object retrieval 및 upload에 signed URL을 사용하고, service account key나 광범위한 IAM permission을 배포하는 것은 피합니다. - 장기 key를 export하는 대신 관리형 service account credential을 사용한 애플리케이션 제어 signing을 선호합니다. 일반적인 오해: 흔한 함정은 IAM Conditions가 모든 임시 액세스 문제를 해결한다고 가정하는 것입니다. 하지만 여전히 유효한 principal identity가 필요합니다. 또 다른 오해는 service account credential을 공유하는 것이 외부 액세스를 위한 허용 가능한 지름길이라는 생각인데, 실제로는 중대한 보안 위험입니다. 또한 요구 사항이 object별 위임일 때는 bucket 수준 IAM이 보통 너무 광범위합니다. 시험 팁: 문제에서 Google account가 없는 외부 사용자와 Cloud Storage에 대한 임시 액세스가 언급되면, signed URL이 보통 가장 좋은 정답입니다. 최소 권한, object 수준 범위, 단기 액세스에 집중하세요. Credential 배포나 외부 당사자에게 광범위한 IAM role을 할당해야 하는 선택지는 제거하세요.

4
문제 4

You are setting up a new workstation to provision Google Cloud infrastructure with Terraform for a video analytics project at AuroraStream. Company policy requires that all resources be created by a dedicated deployment service account (tf-deployer@proj.example.iam.gserviceaccount.com) and forbids downloading long-lived service account keys. Your Cloud Identity user has the iam.serviceAccountTokenCreator role on that service account and the necessary project permissions to run Terraform. You will configure the Terraform Google provider to use impersonate_service_account pointing to the deployment service account. Following Google-recommended best practices, what should you do on your workstation to authenticate Terraform?

오답입니다. service account JSON 키를 다운로드하는 것은 제시된 정책(장기 키 금지)을 위반하며, 키 유출 위험과 운영 오버헤드(로테이션, 폐기) 때문에 Google 모범 사례에서도 명시적으로 권장되지 않습니다. impersonation을 사용할 수 있다면 Terraform는 배포 service account에 대한 키 파일이 필요 없고, 대신 단기 토큰을 발급해야 합니다.

오답입니다. gcloud auth/impersonate_service_account 및 GOOGLE_OAUTH_ACCESS_TOKEN을 export하는 방식은 일부 임시(ad-hoc) 시나리오에서는 동작할 수 있지만, 토큰이 단기이며 수동으로 갱신해야 하므로 Terraform에는 취약합니다. 또한 Terraform와 Google libraries가 기대하는 표준 ADC 흐름을 우회하여, ADC + provider impersonation을 사용하는 것보다 자동화와 재현성이 떨어집니다.

정답입니다. gcloud auth application-default login은 워크스테이션에 사용자 기반 Application Default Credentials를 생성합니다. Terraform는 이 ADC를 source credential로 사용한 뒤 impersonate_service_account를 통해 배포 service account를 impersonate하여, service account 키를 다운로드하지 않고도 모든 리소스 작업이 tf-deployer@…로 수행되도록 보장할 수 있습니다. 이는 Google이 권장하는 키 없는(keyless) 단기 credential 접근 방식에 부합합니다.

오답입니다. Vault가 키를 동적으로 전달하더라도, 여전히 장기 credential인 service account JSON 키에 의존하며 정책에서 이를 명시적으로 금지합니다. 이 접근은 핵심 요구사항을 해결하지 못한 채 복잡성과 운영 부담(Vault 통합, secret 라이프사이클)만 추가합니다. Google이 선호하는 해법은 단기 토큰을 사용하는 키 없는 impersonation입니다.

문제 분석

핵심 개념: 이 문제는 service account impersonation을 사용하고 장기 키를 피할 때, Infrastructure as Code 도구(Terraform)를 위한 Google Cloud 인증 모범 사례를 평가합니다. 핵심 서비스/개념은 Application Default Credentials (ADC), IAM service account impersonation (iam.serviceAccountTokenCreator), 그리고 Terraform Google provider의 impersonate_service_account 설정입니다. 정답이 맞는 이유: Terraform를 impersonate_service_account로 구성하더라도, 대상 배포 service account를 위한 단기 토큰을 발급하기 위해 IAM Credentials API (generateAccessToken)를 호출할 초기 “source” credential이 여전히 필요합니다. 개발자 워크스테이션에서 Google이 권장하는 모범 사례는 gcloud auth application-default login을 통한 사용자 기반 ADC를 사용하는 것입니다. 이는 Terraform가 자동으로 발견할 수 있는 로컬 ADC를 생성하고, 이후 Terraform는 해당 사용자 credential을 오직 tf-deployer@…를 impersonate하는 데만 사용하여 모든 리소스를 생성합니다. 이는 정책(전용 service account가 리소스를 생성)을 충족하면서 장기 service account 키를 다운로드하지 않도록 합니다. 핵심 기능 / 구성: - ADC는 Google client libraries와 Terraform Google provider가 사용하는 표준 credential discovery 메커니즘을 제공합니다. - Service account impersonation은 단기 access token을 생성하여 영향 범위를 줄이고, Google Cloud Architecture Framework의 보안 원칙인 “단기 credential 사용” 및 “최소 권한”에 부합합니다. - 필요한 IAM: 사용자에게 대상 service account에 대한 iam.serviceAccountTokenCreator 권한이 필요하며, 대상 service account에는 리소스를 생성/관리하는 데 필요한 project role이 필요합니다. 흔한 오해: - Terraform가 JSON 키를 통해 service account로 직접 인증해야 한다고 생각하는 경우가 많습니다(impersonation을 사용할 수 있다면 그렇지 않습니다). - access token을 수동으로 export하는 방식은 가능해 보이지만 Terraform에 권장되는 워크플로가 아니며, 토큰 만료로 인해 자동화가 오류에 취약해집니다. - Vault에 키를 저장하는 방식은 여전히 장기 키에 의존하며, 정책에서 이를 명시적으로 금지합니다. 시험 팁: 워크스테이션 기반 Terraform에서 impersonation을 사용할 때는 다음 패턴을 기억하세요: (1) 사용자로서 ADC 획득(gcloud auth application-default login), (2) provider에 impersonate_service_account 구성, (3) iam.serviceAccountTokenCreator 및 필요한 project 권한이 설정되어 있는지 확인. 가능하면 service account 키 대신 ADC + impersonation을 우선하세요.

5
문제 5

You are preparing nightly releases of a serverless event-processing platform on Cloud Run across two regions. Each day at 18:00 UTC, your CI/CD pipeline builds and pushes 30–40 distinct Linux-based container images to a single Artifact Registry Docker repository, and the production rollout begins at 20:00 UTC. Security requires that you be alerted to any known OS-level vulnerabilities in the newly pushed images before the rollout, and you want to follow Google‑recommended best practices without adding custom scanning code to your pipeline. What should you do?

오답입니다. gcloud CLI를 사용해 scan을 호출하면 각 이미지에 대해 scanning을 트리거하는 명시적인 운영 단계가 추가되는데, Artifact Registry가 이미 자동 vulnerability scanning과 통합되어 있을 때 이는 불필요합니다. 이 접근 방식은 피할 수 있는 pipeline 복잡성을 추가하며, custom scanning logic을 피해야 한다는 요구 사항에도 부합하지 않습니다. 여기서 Google 모범 사례는 scan을 수동으로 orchestration하는 대신 이미지 push 시 관리형 scanning에 의존하는 것입니다.

정답입니다. Artifact Registry에 대해 Container Analysis를 활성화하면 지원되는 이미지가 push될 때 자동으로 scan되므로, 이는 야간 build-and-push workflow에 직접적으로 부합합니다. 이는 CI/CD pipeline에 custom scanning code나 명시적인 scan-triggering 단계를 추가하지 않고도 20:00 rollout 전에 알려진 OS 수준 vulnerability를 식별해야 한다는 요구 사항을 충족합니다. 배포 전에 보고된 vulnerability 결과를 검토하는 것은 이 시나리오에서 release validation을 위한 관리형의 Google 권장 접근 방식입니다.

오답입니다. Container Analysis를 활성화하고 자동 scanning에 의존하는 것은 올바른 기반이지만, CRITICAL vulnerability만 검토하는 것은 제시된 요구 사항에 비해 너무 제한적입니다. 문제에서는 rollout 전에 새로 push된 이미지의 알려진 모든 OS 수준 vulnerability에 대해 경고를 받아야 한다고 했으므로, 가장 높은 severity만 필터링하는 것이 아니라 보고된 모든 vulnerability findings를 고려해야 함을 의미합니다. Severity 기반 triage는 운영상 유용할 수 있지만, 이 문제의 문구를 완전히 충족하지는 못합니다.

오답입니다. 이미지별로 scan을 트리거하기 위해 Container Analysis REST API를 호출하면 pipeline에 custom integration 및 orchestration logic이 필요하며, 이는 문제에서 명시적으로 피하고자 하는 부분입니다. 또한 Artifact Registry는 관리형 통합을 통해 push된 이미지에 대한 vulnerability findings를 자동으로 생성할 수 있으므로 이것도 불필요합니다. 시험 관점에서 수동 API 기반 triggering은 내장된 scanning workflow를 활성화하는 것보다 덜 바람직합니다.

문제 분석

핵심 개념: Artifact Registry는 Container Analysis와 통합되어, 이미지가 push될 때 지원되는 container image에 대해 OS package vulnerability를 자동으로 scan합니다. 정답인 이유: 요구 사항은 새로 push된 이미지가 배포되기 전에 알려진 OS 수준 vulnerability를 탐지하면서 custom scanning code는 피하는 것이므로, 관리형 자동 scanning workflow가 권장되는 접근 방식입니다. 주요 기능: push 시 자동 scanning, vulnerability metadata가 저장되고 Google Cloud tooling을 통해 확인 가능, 그리고 gcloud 또는 REST를 통해 수동으로 scan을 트리거할 필요가 없습니다. 흔한 오해: scan을 직접 호출할 필요가 없으며, 검토를 CRITICAL findings로만 제한하는 것은 알려진 모든 vulnerability를 포착해야 한다는 요구 사항을 충족하지 못합니다. 시험 팁: 문제가 Google 권장 모범 사례와 custom pipeline logic이 없음을 강조하면, 수동 API 또는 CLI orchestration보다 Artifact Registry와 Container Analysis의 완전 관리형 통합을 선택하세요.

이동 중에도 모든 문제를 풀고 싶으신가요?

Cloud Pass를 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.

6
문제 6

You are configuring a Cloud Build trigger for a Node.js REST service that builds a Docker image and pushes it to Artifact Registry (us-central1, repository 'apis') with the tag $SHORT_SHA. Compliance requires the pipeline to first run unit tests and then run integration tests against a disposable test database before the image is pushed. If any test fails, you must be able to tell from the Cloud Build history exactly which stage (unit or integration) failed without reading through logs. What should you do?

Dockerfile에서 RUN으로 테스트를 실행하는 것은 CI 단계 리포팅에 적합하지 않습니다. Cloud Build는 일반적으로 “docker build” step에서의 실패로만 표시되며, “unit” vs “integration”을 구분해 보여주지 않으므로 어떤 테스트가 실패했는지 알려면 로그가 필요합니다. 또한 build 시간이 늘고, 신중하게 multi-stage를 구성하지 않으면 테스트 도구가 image layer에 섞여 들어갈 수 있습니다. 컴플라이언스는 push 전에 명시적인 파이프라인 단계를 원합니다.

unit test와 integration test를 모두 실행하는 단일 Cloud Build step(예: 하나의 bash command)은 Cloud Build history에 단 하나의 step 상태만 보고합니다. 실패 시 history만으로는 unit인지 integration인지 구분할 수 없고, 로그를 읽거나 exit code를 파싱해야 합니다. 이는 단계 수준의 실패 가시성 요구사항을 위반합니다.

unit test와 integration test를 위해 별도의 Cloud Build 파이프라인을 트리거하면 복잡도(빌드 체이닝, source/metadata 전달, 승인 처리)가 증가하고 감사 추적이 분절될 수 있습니다. 또한 원래 트리거에 대한 단일 build history 엔트리 내에서 “어떤 단계가 실패했는지”를 자동으로 더 명확하게 보장하지도 않습니다. 요구사항은 여러 step을 사용하는 하나의 파이프라인 내에서 가장 잘 충족됩니다.

서로 다른 ID(예: id: unit-tests, id: integration-tests)를 가진 별도의 Cloud Build step은 Cloud Build history에서 명확한 step-level 상태를 제공합니다. step은 기본적으로 순서대로 실행되므로 unit test를 먼저, 그다음 ephemeral database에 대한 integration test를 수행하고, 그 후에만 $SHORT_SHA로 Artifact Registry에 Docker image를 build/push하게 됩니다. 이는 컴플라이언스 및 관측 가능성 요구사항을 직접 충족합니다.

문제 분석

핵심 개념: 이 문제는 CI 품질 게이트를 위한 Cloud Build 파이프라인 설계를 테스트합니다. 즉, 테스트 단계가 순서대로 강제되도록 build step을 구조화하고, 실패가 Cloud Build history에서 명확히 귀속되도록 하는 것입니다. 또한 Artifact Registry 퍼블리싱 모범 사례(검증 이후에만 artifact를 push)도 다룹니다. 정답이 맞는 이유: unit test와 integration test를 각각 별도의 Cloud Build step으로 분리하고(서로 다른 step ID 사용), 이를 Docker build/push 이전에 배치하면 Cloud Build UI와 build history에서 명시적인 단계 경계가 생깁니다. Cloud Build는 각 step의 상태(success/failure)와 실패한 step ID를 로그를 열어보지 않아도 보여줍니다. step은 기본적으로 순차 실행되므로(waitFor를 사용하지 않는 한), “unit-tests”를 먼저, “integration-tests”를 두 번째로 두면 요구된 순서가 보장됩니다. 두 테스트가 모두 성공한 뒤에만 Docker build를 수행하고 $SHORT_SHA 태그로 Artifact Registry에 push해야 합니다. 핵심 기능 / 모범 사례: - Step 세분화: 각 step은 Cloud Build history에서 1급 엔터티이며, 고유한 ID는 컴플라이언스 감사와 트러블슈팅을 더 빠르게 합니다. - 순서 보장 실행: 기본 순차 실행으로 unit 다음 integration 테스트를 강제하며, 실수로 병렬 실행되는 것을 방지하려면 waitFor를 명시적으로 설정할 수도 있습니다. - 일회성 테스트 데이터베이스: integration test는 전용 step 내에서 ephemeral dependency(예: Auth Proxy를 통한 Cloud SQL, 임시 database/schema, 또는 containerized DB)를 띄운 뒤, 같은 step에서 teardown하여 비용을 통제하고 상태 누수를 방지할 수 있습니다. - Artifact 승격: 테스트 통과 후에만 build 및 push하는 것은 supply-chain 및 릴리스 위생 관행에 부합합니다. 흔한 오해: - Dockerfile에 테스트를 넣는 것(option A)은 image build와 CI 검증을 혼합하여 실패가 일반적인 “docker build failed”로 보이게 만들고, 어떤 테스트 단계가 실패했는지 가립니다. - 테스트를 한 step에 합치는 것(option B)은 Cloud Build step 수준에서 어떤 단계가 실패했는지 여전히 숨깁니다. unit vs integration 실패를 구분하려면 로그가 필요합니다. - 파이프라인을 분리하는 것(option C)은 오케스트레이션 복잡도를 늘리고 build별 단계 가시성을 본질적으로 개선하지 않습니다. 또한 artifact/SHA 전달과 단일 감사 가능한 흐름 강제를 복잡하게 만들 수 있습니다. 시험 팁: Cloud Build 문제에서 어떤 단계가 실패했는지의 가시성이 요구되면, 명확한 ID를 가진 여러 step을 선호하세요. “테스트 실패 시 publish 금지”라면 push step이 테스트 step 이후에 오도록 하세요. Cloud Build history는 step-level 상태를 노출하며, 단일 step 내부의 sub-command 단위 세분성은 제공하지 않는다는 점을 기억하세요.

7
문제 7

Your organization runs a Cloud Build CI/CD pipeline with 4 build steps for a Python API: (1) run unit tests, (2) generate a 6 KB text report containing the commit SHA and changed files, (3) build and push a container image, and (4) run a security gate that consumes the report; the report must be accessible to steps 3 and 4 within the same build and must not be persisted after the build; the pipeline executes up to 30 times per hour. How should you store the report so that all required build steps can access it?

Compute Engine instance metadata는 VM instance와 연관되는 것이며, Cloud Build의 step 간 artifact 공유를 위한 것이 아닙니다. Cloud Build는 container에서 관리형 build step을 실행하며, step 간에 생성된 파일을 전달하기 위한 지원되는 임시 저장 공간으로 instance metadata를 제공하지 않습니다. 또한 metadata는 반복적으로 일시적인 CI artifact를 기록하기 위한 것이 아니라 configuration 및 bootstrap information을 위한 용도입니다. 여기서 이를 사용하는 것은 지원되지 않으며, 운영상 불편하고, 일반적인 Cloud Build 설계 패턴에도 어긋납니다.

정답입니다. Cloud Build에서 /workspace는 동일한 build의 각 step에 마운트되는 공유 filesystem path이므로, step 2에서 그곳에 기록한 파일은 step 3과 4에서 직접 읽을 수 있습니다. 이는 추가 전송 메커니즘 없이 report를 이후 여러 step에서 사용할 수 있어야 한다는 요구 사항을 직접 충족합니다. report는 현재 build 동안에만 필요하므로, /workspace를 사용하면 Cloud Storage와 같은 외부 시스템에 불필요하게 영속 저장하는 일을 피할 수 있습니다. 또한 latency, IAM 의존성, cleanup logic을 최소화하므로 가장 단순하고 신뢰할 수 있는 설계이기도 합니다.

Cloud Storage는 외부 object store이므로, report를 այնտեղ 업로드하면 명시적인 deletion 또는 lifecycle management를 추가하지 않는 한 build 외부에 영속 저장됩니다. 이는 정상적인 설계의 일부로서 build 후 report가 저장되지 않아야 한다는 요구 사항과 충돌합니다. 또한 하나의 build 내에서만 공유하면 되는 매우 작은 파일에 대해 불필요한 network operation, IAM permission, 그리고 잠재적인 failure point를 추가합니다. Cloud Storage는 현재 build 실행을 넘어 보관되거나 공유되어야 하는 artifact에 더 적합합니다.

report를 외부 web service에 게시하는 것은 단순한 build 내부 handoff에 불필요한 의존성을 도입합니다. 해당 service는 authentication, availability, 그리고 경우에 따라 자체 storage semantics까지 필요하므로 복잡성과 failure mode가 모두 증가합니다. 또한 build 외부에 report가 영속 저장될 위험이 있어 요구 사항과도 맞지 않습니다. 동일한 build의 이후 step에서만 필요한 작은 임시 파일이라면, Cloud Build의 공유 workspace가 의도된 훨씬 더 단순한 해결책입니다.

문제 분석

핵심 개념: Cloud Build는 /workspace에 마운트된 공통 작업 디렉터리를 공유하는 일련의 step으로 build를 실행합니다. 한 step이 /workspace에 작성한 파일은 동일한 build 내의 후속 step에서 사용할 수 있지만, 이는 ephemeral하며 build가 끝나면 폐기됩니다. 이는 외부에 영구 저장하지 않고 step 간에 작은 artifact를 전달하는 표준 패턴입니다. 정답이 맞는 이유: 요구사항은 6 KB report가 동일한 build 내에서 step 3과 step 4가 접근할 수 있어야 하며, build 이후에는 persisted되면 안 된다는 것입니다. step 2에서 report를 /workspace에 쓰고 step 3과 step 4에서 동일한 경로로 읽으면 두 조건을 모두 충족합니다. step 간 공유가 가능하고, 외부 service가 필요 없으며, build 완료 시 자동으로 정리됩니다. 또한 build마다 격리된 /workspace를 가지므로 build 간 경합을 피할 수 있어 시간당 30회 실행에도 자연스럽게 확장됩니다. 주요 기능 / Best Practices: - /workspace는 모든 build step 간에 공유되는 volume입니다. intermediate artifact(report, compiled asset, generated config)에 사용하세요. - build 내부에서만 필요한 artifact는 작고 로컬로 유지하세요. 이렇게 하면 latency, cost, failure mode를 줄일 수 있습니다. - 이는 Google Cloud Architecture Framework 원칙(reliability 및 operational excellence)과도 부합합니다. 외부 dependency가 적고 data flow가 단순할수록 pipeline의 견고성이 향상됩니다. 흔한 오해: 흔한 실수는 어떤 artifact든 Cloud Storage를 사용하는 것입니다. Cloud Storage는 동작하긴 하지만 lifecycle rule이나 명시적 deletion을 추가하지 않으면 데이터가 persisted되며, 이는 “build 이후 persisted되면 안 됨” 요구사항을 위반하고 추가 step 및 잠재적인 cleanup 실패를 유발합니다. 또 다른 오해는 instance metadata를 범용 scratchpad로 사용할 수 있다는 것입니다. Cloud Build step은 container이며, 사용자가 제어하는 장기 실행 VM이 아닙니다. 시험 팁: Cloud Build 문제에서는 다음을 기억하세요: (1) /workspace는 step 간 공유되는 filesystem, (2) 각 step은 자체 container에서 실행되지만 /workspace를 공유, (3) artifact가 build 이후에도 살아남아야 하거나 build/project 간 공유되어야 할 때만 외부 storage(Cloud Storage/Artifact Registry)를 사용합니다. 지문이 “동일한 build 내”와 “persisted되지 않음”을 강조한다면, 보통 /workspace가 의도된 해법입니다.

8
문제 8

You operate a city-wide food delivery platform on Google Cloud. An order-processing microservice currently invokes an HTTP Cloud Function to send SMS status updates (order accepted, courier en route) through a third-party SMS gateway. After launching a 30%-off promotion, peak load spiked to about 18,000 notifications per minute, and the Cloud Function intermittently returns HTTP 500 errors. Some customers report missing SMS updates, and logs show the sender aborts on 500 responses without persisting the messages. You need to change how SMS messages are handled to minimize message loss without significantly increasing operational complexity. What should you do?

Cloud Function timeout을 늘리는 것은 핵심적인 신뢰성 문제를 해결하지 못합니다. 발신자는 동기식 HTTP 호출을 수행하고 있으며, 500 응답을 받으면 메시지를 버립니다. 일부 실패가 느린 downstream 응답 때문에 발생하더라도, 더 긴 timeout은 내구성 있는 buffering, retry semantics, 또는 트래픽 급증 시 decoupling을 제공하지 않습니다. 함수가 일시적으로 실패하거나 payload를 영속화하기 전에 발신자가 포기하면 시스템은 여전히 메시지를 잃게 됩니다. 이 옵션은 안정적인 전달을 위해 흐름을 재설계하기보다는 과부하의 증상만 다루고 있습니다.

SMS payload를 Pub/Sub에 publish하면 sender를 Cloud Function과 디커플링하고 트래픽 스파이크 동안 내구적인 buffering을 제공합니다. Pub/Sub은 함수가 실패할 때 retry/redelivery가 포함된 at-least-once delivery를 제공하여 메시지 유실을 크게 줄입니다. Pub/Sub-triggered Cloud Function은 자동으로 확장되며, dead-letter topic 및 idempotent processing과 결합해 반복 실패를 최소한의 운영 복잡도로 안전하게 처리할 수 있습니다.

Memorystore(Redis)를 중간 store/queue로 사용하면 운영 복잡도와 리스크가 증가합니다. Redis는 주로 in-memory cache이며 queue로 사용할 수는 있지만 persistence 설정, eviction policy, failover 동작, consumer coordination을 관리해야 합니다. Pub/Sub만큼 event ingestion에 대해 단순하거나 내구적이지 않으며, 운영 및 모니터링해야 할 추가 컴포넌트를 도입하게 됩니다.

HTTP Cloud Function을 매초 retry하면 부하 상황에서 retry storm을 유발해 concurrency를 증가시키고 500 오류를 더 발생시키기 쉽습니다. 또한 sender가 크래시하거나 retry 중간에 redeploy되면 내구적 저장을 제공하지 못하며, 신중한 idempotency 없이 duplicate send를 유발할 수 있습니다. client-side retry는 유용하지만, 신뢰성과 스파이크 buffering이 필요할 때 managed queue를 대체할 수는 없습니다.

문제 분석

핵심 개념: 이 문제는 Cloud Functions에 대한 동기식 HTTP 호출 대신 비동기 메시징(Pub/Sub)을 사용해 producer와 consumer를 디커플링함으로써, 신뢰할 수 있고 확장 가능하며 cloud-native한 통합을 설계하는 능력을 평가합니다. 정답이 맞는 이유: 약 18,000 notifications/분(약 300/초)에서 HTTP로 호출되는 Cloud Function이 간헐적으로 500을 반환합니다(대개 일시적인 scaling 한계, downstream latency, 또는 concurrency 압박 때문). sender는 500에서 중단하고 메시지를 저장하지 않기 때문에 notification이 유실됩니다. 각 SMS payload를 Pub/Sub topic에 publish하면 sender의 책임은 “enqueue하고 계속 진행”으로 바뀌며, Pub/Sub이 메시지를 내구적으로 저장하고 at-least-once delivery로 subscriber에 전달합니다. Cloud Function은 Pub/Sub subscription에 의해 트리거되는 event-driven consumer가 되어, 스파이크 동안 자동 scaling과 buffering이 가능합니다. 함수나 SMS gateway에 일시적 장애가 발생하면 Pub/Sub이 redeliver하므로, 큰 운영 부담을 추가하지 않고도 메시지 유실을 크게 줄일 수 있습니다. 주요 기능 / Best Practices: Pub/Sub은 내구적 message retention, backpressure buffering, acknowledgement deadline 기반의 retry/redelivery를 제공합니다. Pub/Sub에 의해 트리거되는 Cloud Functions는 네이티브하게 통합되며 수평 확장합니다. 반복 실패하는 메시지에 대해 dead-letter topic을 구성할 수 있고, at-least-once delivery를 처리하기 위해 idempotency(예: message IDs)를 사용할 수 있습니다. 이는 Google Cloud Architecture Framework의 reliability 원칙(컴포넌트 디커플링, failure를 전제로 설계, managed services로 ops 감소)과 일치합니다. 흔한 오해: 함수( timeout )를 “튜닝”하거나 client retry를 추가하고 싶을 수 있습니다. 하지만 timeout은 메시지 유실 문제를 해결하지 못하고, 공격적인 retry는 부하를 증폭(retry storms)시킬 수 있으며 sender가 크래시하면 여전히 메시지가 유실될 수 있습니다. Redis를 queue로 사용하는 것은 운영 복잡도를 증가시키고 durability/eviction 처리를 신중히 다뤄야 합니다. 시험 팁: (1) 동기식 HTTP 호출, (2) 스파이크, (3) 간헐적 5xx, (4) producer가 persist하지 않아 message loss가 발생—이 조합이 보이면 서비스 사이에 비동기적이고 내구적인 queue(Pub/Sub)를 선택하세요. notification pipeline에서는 idempotency, dead-lettering, 그리고 SLO 지표로 subscription backlog/age 모니터링도 함께 고려하세요.

9
문제 9

You are launching a single App Engine Standard application (service: default, region: us-central1) and must make it accessible only at http://www.northwind.news/; your DNS is hosted in Cloud DNS (zone: public-zone, TTL: 300s), the domain is not yet verified, and you do not require any path- or service-based routing—what should you do?

정답입니다. App Engine 커스텀 도메인은 먼저 도메인 소유권 검증이 필요합니다. www.northwind.news 같은 서브도메인의 표준 DNS 구성은 ghs.googlehosted.com을 가리키는 CNAME입니다. 이는 Google의 managed front end를 활용하고 IP 관리를 피할 수 있습니다. 기본 서비스만 사용하고 라우팅 요구사항이 없으므로 dispatch.yaml 규칙은 필요하지 않습니다.

오답입니다. App Engine의 서브도메인 커스텀 도메인 매핑은 일반적으로 “단일 global App Engine IP”로의 A 레코드가 아니라 ghs.googlehosted.com으로의 CNAME으로 수행합니다. 단일 IP로의 A 레코드 패턴은 보통 reserved global static IP를 사용하는 external HTTP(S) load balancer에 더 부합하며, App Engine 도메인 매핑을 직접 하는 방식이 아닙니다.

오답입니다. ghs.googlehosted.com으로의 CNAME은 올바른 DNS 접근이지만, 여기서는 dispatch.yaml이 불필요합니다. dispatch.yaml은 호스트/경로 규칙에 따라 여러 App Engine 서비스(또는 버전)로 요청을 라우팅할 때 사용합니다. 서비스가 하나(default)이고 라우팅 요구사항이 없으므로 dispatch 규칙을 추가하면 이점 없이 복잡도만 증가합니다.

오답입니다. 이 시나리오에서 두 가지 잘못된 아이디어를 결합했습니다. 라우팅 요구사항이 없는 단일 서비스 앱에는 dispatch.yaml이 필요하지 않고, 서브도메인을 App Engine에 매핑하는 권장/일반적인 방식은 “단일 global App Engine IP”로의 A 레코드가 아닙니다. 올바른 접근은 검증 + ghs.googlehosted.com으로의 CNAME입니다.

문제 분석

핵심 개념: 이 문제는 Cloud DNS를 사용하여 커스텀 도메인을 App Engine Standard 앱에 매핑하는 방법을 평가하며, 필요한 도메인 검증 단계와 올바른 DNS 레코드 유형을 포함합니다. 또한 dispatch.yaml이 필요한 경우(호스트/경로 라우팅)와 App Engine의 기본 서비스 매핑만으로 충분한 경우를 구분하는지도 확인합니다. 정답이 맞는 이유: www.northwind.news 같은 커스텀 호스트네임에서 App Engine 앱을 제공하려면 (1) Google에서 도메인 소유권을 검증(일반적으로 Google Search Console / Webmaster Central 검증)하고 (2) DNS를 구성하여 해당 호스트네임이 App Engine을 가리키도록 해야 합니다. App Engine에서 서브도메인(www)에 대한 표준이자 권장되는 방식은 ghs.googlehosted.com을 가리키는 CNAME 레코드입니다. 그러면 App Engine이 요청을 종료(terminate)하고, 검증된 도메인 매핑을 기반으로 올바른 애플리케이션으로 라우팅합니다. 기본 서비스만 사용하고 호스트 기반 또는 경로 기반 라우팅이 필요하지 않으므로 dispatch.yaml은 필요하지 않습니다. 주요 기능 / 모범 사례: - 도메인 검증은 App Engine이 커스텀 도메인 매핑을 수락하기 전에 필수이며, 하이재킹을 방지합니다. - 서브도메인의 경우 ghs.googlehosted.com으로 CNAME을 사용합니다(Google-managed front end). 이는 IP를 관리할 필요가 없고 Google의 global edge를 지원합니다. - Cloud DNS TTL(300s)은 전파 속도에 영향을 주며, 외부 리졸버 캐싱까지 고려하면 수 분 이상 걸릴 수 있습니다. - App Engine Standard는 리전이 us-central1이더라도 전 세계적으로 제공되며, 커스텀 도메인 매핑은 단일 리전 IP에 종속되지 않습니다. 흔한 오해: 자주 있는 함정은 “단일 global App Engine IP”로 A 레코드를 지정할 수 있다고 생각하는 것입니다. App Engine의 커스텀 도메인에 대한 권장 구성은 서브도메인에 CNAME을 사용하는 것이며, 고정 IP A 레코드는 보통 reserved global static IP를 사용하는 external HTTP(S) load balancer와 연관되고 App Engine 커스텀 도메인 매핑을 직접 하는 방식이 아닙니다. 또 다른 오해는 호스트네임에 dispatch.yaml이 필요하다는 생각인데, 이는 여러 서비스가 있고 라우팅 규칙이 필요할 때만 사용합니다. 시험 팁: - 호스트네임이 서브도메인(www)이라면 ghs.googlehosted.com으로 CNAME을 예상하세요. - 안정적인 IP 또는 고급 라우팅 요구사항이 있으면 direct App Engine A records가 아니라 “External HTTP(S) Load Balancer + serverless NEG”를 떠올리세요. - 경로/서비스 라우팅 요구사항이 없고 서비스가 하나뿐이면 dispatch.yaml은 불필요합니다. - 도메인이 아직 검증되지 않았다면, 항상 도메인 검증을 선행 조건으로 포함하세요.

10
문제 10

You are the lead developer for a city transit incident dashboard running on Cloud Run (512 MiB memory per instance, max 80 concurrent requests) backed by Firestore in Native mode; the web UI provides infinite scroll so users can browse all incident reports, and three months after launch you observe that during 07:30–09:30 peak hours several Cloud Run instances return HTTP 500 with out-of-memory errors while Firestore read throughput spikes to ~250 QPS. You need to stop Cloud Run from crashing and reduce Firestore reads using a performance-optimized approach without merely increasing resource limits; what should you do?

안정적인 orderBy와 고정된 limit을 사용하는 cursor-based pagination(startAfter/startAt)은 infinite scroll을 위한 성능 최적화된 Firestore 패턴입니다. 각 페이지는 다음 N개의 document만 읽으므로 Cloud Run에서 메모리 사용량이 제한되고, 사용자가 더 깊게 스크롤할수록 read amplification이 발생하는 것을 방지합니다. 안정적인 sort key(예: timestamp + doc ID)를 사용하면 duplicate를 방지하고 concurrent writes 상황에서도 일관된 paging을 보장합니다.

Composite index는 특정 multi-field filter/orderBy 조합에 필요할 수 있으며 query latency를 줄이거나 query 자체를 가능하게 할 수 있습니다. 하지만 이는 설명된 핵심 문제(무제한 pagination으로 인한 큰 응답과 반복 reads)를 해결하지 못합니다. 앱이 이미 query를 수행할 수 있다면, index만 추가해도 OOM을 막거나 비효율적인 paging으로 인해 발생하는 read QPS를 줄이지는 못합니다.

Offset-based pagination과 limit은 Firestore에서 비효율적입니다. 백엔드는 offset까지의 document를 여전히 스캔/스킵해야 합니다. offset이 커질수록 각 요청은 더 비싸지고(더 많은 reads, 더 높은 latency), Firestore throughput이 급증하며, 처리 오버헤드가 커져 Cloud Run memory/CPU 사용량도 증가할 수 있습니다. 이는 Firestore에서 deep pagination에 대한 흔한 anti-pattern입니다.

Cloud Run memory를 512 MiB에서 1 GiB로 늘리면 즉각적인 OOM 크래시는 줄일 수 있지만, 프롬프트에서 명시적으로 금지되어 있으며(“without merely increasing resource limits”), Firestore reads를 줄이지도 못합니다. 또한 instance당 비용을 증가시키고, 요청이 계속 큰 in-memory 결과 세트나 payload를 구성한다면 피크 concurrency에서 여전히 실패할 수 있습니다.

문제 분석

핵심 개념: 이 문제는 Firestore를 백엔드로 사용하는 serverless 앱(Cloud Run)의 확장 가능한 데이터 접근 패턴, 특히 pagination 전략이 메모리 사용량, latency, 그리고 Firestore read amplification에 어떤 영향을 주는지 평가합니다. 이는 Google Cloud Architecture Framework의 performance optimization 및 cost optimization 원칙과 일치합니다. 정답이 맞는 이유: Infinite scroll은 종종 반복적인 “load more” 호출로 이어집니다. 백엔드가 offset-based pagination을 사용하거나 컬렉션의 큰 부분을 다시 읽는 방식이라면, 각 후속 요청은 점점 더 큰 결과 세트를 스캔하고 반환하게 되어 Firestore reads가 증가하고 Cloud Run handler가 큰 in-memory array/JSON payload를 할당하게 됩니다. 안정적인 sort key(예: orderBy(timestamp, docId) 및 limit 50)와 함께 cursor-based pagination(startAfter/startAt)을 사용하면 각 요청이 다음 페이지에 해당하는 데이터만 읽습니다. 이는 요청당 메모리와 응답 크기를 제한하고, 사용자 액션당 Firestore reads를 줄이며, 피크 트래픽 동안 성능을 안정화합니다. 주요 기능 / Best Practices: Firestore query cursor를 사용하고 indexed field에 대해 orderBy를 적용하며, deterministic tie-breaker(대개 document ID)를 추가해 여러 incident가 동일한 timestamp를 공유할 때 duplicate/holes가 발생하지 않도록 합니다. 고정된 limit(예: 50)을 유지하고 UI에 “nextPageToken”(cursor 값)을 반환합니다. 이 패턴은 대규모 컬렉션과 infinite scroll에 권장되는 접근 방식으로, 사용자가 더 깊게 스크롤할수록 O(n) 작업이 발생하는 것을 방지합니다. 흔한 오해: Index 생성(option B)은 query의 가능 여부/latency를 개선할 수 있지만, 잘못된 pagination으로 인해 발생하는 reads를 본질적으로 줄이지는 않습니다. Offset pagination(option C)은 개념적으로는 쉽지만 Firestore에서는 비효율적입니다. offset이 커질수록 많은 document를 스캔/스킵해야 하므로 read operation과 latency가 증가합니다. Cloud Run memory 증가(option D)는 증상(OOM)만 완화할 뿐 원인(무제한 결과 처리 및 read amplification)을 해결하지 못하며, 비용을 증가시키고 피크 안정성을 보장하지도 못합니다. Exam Tips: Firestore + “infinite scroll” + reads/latency/OOM 급증을 보면 “limit을 둔 cursor-based pagination”을 떠올리세요. Firestore에서 deep pagination에는 offset을 피하세요. 또한 Cloud Run concurrency로 인해 하나의 instance가 동시에 많은 요청을 처리할 수 있다는 점을 기억하세요. 각 요청이 큰 응답을 구성하면 메모리 압박이 빠르게 누적됩니다. 리소스를 단순히 확장하기보다 요청당 작업량과 payload 크기를 제한하는 설계를 선호하세요.

합격 후기(6)

V
V***********Nov 24, 2025

학습 기간: 2 months

The scenarios in this app were extremely useful. The explanations made even the tricky deployment questions easy to understand. Definitely worth using.

B
B************Nov 21, 2025

학습 기간: 2 months

The questions weren’t just easy recalls — they taught me how to approach real developer scenarios. I passed this week thanks to these practice sets.

철
철**Nov 17, 2025

학습 기간: 1 month

1개월 구독하니 빠르게 풀어야 한다는 강박이 생기면서 더 열심히 공부하게 됐던거 같아요. 다행히 문제들이 비슷해서 쉽게 풀 수 있었네요

이
이**Nov 15, 2025

학습 기간: 1 month

이 앱의 문제들과 실제 시험 문제들이 많이 비슷해서 쉽게 풀었어요! 첫 시험만에 합격하니 좋네요 굿굿

R
R***********Nov 6, 2025

학습 기간: 1 month

I prepared for three weeks using Cloud Pass and the improvement was huge. The difficulty level was close to the real Cloud Developer exam, and the explanations helped me fill in my knowledge gaps quickly.

다른 모의고사

Practice Test #2

50 문제·120분·합격 700/1000

Practice Test #3

50 문제·120분·합격 700/1000

Practice Test #4

50 문제·120분·합격 700/1000
← 모든 Google Professional Cloud Developer 문제 보기

지금 학습 시작하기

Cloud Pass를 다운로드하고 모든 Google Professional Cloud Developer 기출 문제를 풀어보세요.

Get it on Google PlayDownload on the App Store
Cloud PassCloud Pass

IT 자격증 문제풀이 앱

Get it on Google PlayDownload on the App Store

자격증

AWSGCPMicrosoftCiscoCompTIADatabricks

법률

FAQ개인정보 처리방침서비스 약관

회사

문의하기계정 삭제

© Copyright 2026 Cloud Pass, All rights reserved.

이동 중에도 모든 문제를 풀고 싶으신가요?

앱 받기

Cloud Pass를 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.