CloudPass LogoCloud Pass
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
Certifications
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
  1. Cloud Pass
  2. GCP
  3. Google Professional Cloud Database Engineer
Google Professional Cloud Database Engineer

GCP

Google Professional Cloud Database Engineer

163+ 기출 문제 (AI 검증 답안 포함)

Free questions & answers실제 시험 기출 문제
AI-powered explanations상세 해설
Real exam-style questions실제 시험과 가장 유사
163+ 문제 보기

AI 기반

3중 AI 검증 답안 및 해설

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

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

시험 도메인

Design Innovative, Scalable, and Highly Available Cloud Database Solutions출제율 32%
Manage a Solution that Can Span Multiple Database Technologies출제율 25%
Migrate Data Solutions출제율 23%
Deploy Scalable and Highly Available Databases in Google Cloud출제율 20%

실전 문제

1
문제 1

Your media-streaming platform uses Memorystore for Redis (Standard Tier, Redis 6.x) as a cache for user session tokens and frequently requested metadata; during live event traffic spikes, p95 cache latency jumps from 6 ms to 180–250 ms, and Cloud Monitoring shows memory utilization at 95–98% with Redis INFO reporting ~25,000 evicted_keys/min and an eviction policy of allkeys-lru; average key size is ~1.5 KB, average TTL is 5 minutes, CPU stays under 40%, and network RTT between your GKE cluster and the Redis instance is ~1 ms in the same region; you need to reduce the frequency and impact of these latency spikes. What should you do?

TTL을 늘리면 entry가 cache에 더 오래 남아 hit rate를 개선할 수 있지만, 이는 충분한 memory headroom이 있을 때만 가능합니다. 여기서는 memory가 이미 95–98%이고 eviction이 대량으로 발생합니다. 더 긴 TTL은 resident set size를 늘리고 자연 expiration을 줄여, allkeys-lru 하에서 eviction pressure와 churn을 보통 증가시킵니다. 이는 spike 동안 tail latency와 miss storm을 줄이기보다 악화시키는 경우가 많습니다.

workload를 같은 zone으로 옮기면 cross-zone latency를 줄일 수 있지만, 측정된 RTT는 이미 같은 region에서 ~1 ms이고 CPU도 포화가 아닙니다. 지배적인 증상은 network delay가 아니라 memory pressure와 높은 eviction입니다. 또한 Memorystore Standard Tier는 HA를 위해 replica를 갖는 regional 구성입니다. app을 한 zone에 고정하면 resilience를 낮출 수 있고 eviction-driven latency spike를 해결하지 못합니다.

더 큰 memory tier로 resizing하는 것은 근본 원인(거의 한계에 가까운 memory utilization과 매우 높은 eviction rate)을 직접 해결합니다. 더 많은 RAM은 eviction 빈도를 줄이고 cache hit rate를 안정화하며 p95 spike에 기여하는 eviction bookkeeping overhead를 피하게 합니다. 이는 working set과 overhead가 사용 가능한 memory를 초과할 때 Memorystore의 주요 scaling 메커니즘입니다.

추가 replica(read scaling)는 primary가 read에서 CPU-bound이거나 client connection이 throughput을 포화시킬 때 도움이 될 수 있습니다. 이 시나리오에서는 CPU가 40% 미만이고 문제는 eviction/memory pressure입니다. replica는 write에 대한 primary의 memory capacity를 늘리지 못하고 primary에서의 eviction을 방지하지도 못합니다. 또한 replication overhead와 cost만 추가하고 근본 원인을 해결하지 못합니다.

문제 분석

핵심 개념: 이 문제는 Memorystore for Redis (Standard Tier)에서 부하 시 Redis cache latency를 진단하고 올바른 scaling 레버를 선택하는지를 테스트합니다. 핵심 신호는 memory pressure(95–98%), 높은 eviction rate(~25,000 evicted_keys/min), allkeys-lru policy, 그리고 낮은 CPU/network latency입니다. 정답이 맞는 이유: p95 latency spike는 극단적인 memory utilization과 과도한 eviction과 상관관계가 있습니다. allkeys-lru에서는 Redis가 지속적으로 key를 샘플링하고, LRU metadata를 업데이트하며, 새로운 write를 수용하기 위해 item을 evict해야 합니다. bursty traffic에서는 이것이 churn을 만듭니다: hot key가 evict되어 cache miss가 발생하고, backend fetch가 늘어나며, 추가적인 cache repopulation write가 발생해 latency를 증폭시킵니다. CPU가 <40%이고 RTT가 ~1 ms이므로 bottleneck은 compute나 network가 아니라 working set과 write rate 대비 memory capacity입니다. 더 큰 memory tier로 resizing하면 사용 가능한 RAM이 증가하고 eviction 빈도가 줄어들며 hit rate가 안정화되고 eviction-driven tail latency가 제거됩니다. 주요 기능 / best practices: Memorystore capacity는 instance당 고정되어 있으며, memory가 거의 가득 차면 Redis eviction 동작이 성능을 지배합니다. best practice는 일반적인 utilization이 한계보다 충분히 낮게 유지되도록 Redis를 sizing하는 것입니다(워크로드에 따라 보통 ~60–80%를 목표로 하여 spike, fragmentation, overhead를 흡수). 또한 average key size(1.5 KB)에 Redis object overhead와 TTL bookkeeping이 더해지므로 key당 실제 memory 사용량은 payload size보다 큽니다. Standard Tier는 replication/failover로 HA를 제공하지만, 자동으로 memory를 추가하지는 않습니다. scale up(또는 필요 시 application layer에서 shard)해야 합니다. 흔한 오해: network를 원인으로 의심하기 쉽지만(RTT는 이미 ~1 ms), replica를 추가하는 것도 유혹적이지만(replica는 write-side memory capacity를 늘리지 못하고 primary의 eviction을 멈추지 못함) 둘 다 핵심 원인을 해결하지 못합니다. TTL을 늘리면 hit rate가 좋아질 것 같지만, memory가 이미 포화된 상태에서는 residency time이 늘어나 eviction과 churn을 악화시킵니다. 시험 팁: 높은 memory utilization과 낮은 CPU와 함께 evicted_keys가 높게 보이면 “cache capacity 부족/working set이 너무 큼”을 떠올리고 memory scale-up(또는 redesign/shard)을 선택하세요. replica는 read scaling에 도움이 되지, memory pressure에는 도움이 되지 않습니다. TTL 변경은 memory headroom을 기준으로 평가해야 하며, pressure 상황에서 TTL을 늘리면 보통 악영향을 줍니다.

2
문제 2

Your healthcare analytics company is migrating a self-managed PostgreSQL 12 database from an on-premises datacenter to Cloud SQL for PostgreSQL; after cutover, the system must tolerate a single-zone outage in the target region with no more than 3 minutes of disruption (RTO ≤ 3 minutes) and zero transaction loss (RPO = 0), and you want to follow Google-recommended practices for the migration—what should you do?

Nightly automated backups는 고가용성이 아니라 disaster recovery 메커니즘입니다. outage 중 backup에서 복구하는 데는 일반적으로 3분보다 훨씬 오래 걸립니다(instance provisioning, restore 시간, DNS/app 재구성). 따라서 RTO 요구사항을 충족하지 못합니다. 또한 마지막 backup 이후의 트랜잭션이 손실될 수 있으므로 RPO = 0도 보장할 수 없습니다. backups는 여전히 중요하지만, 명시된 목표를 충족하지는 못합니다.

secondary instance로의 CDC/logical replication 파이프라인은 운영이 복잡하며 Cloud SQL에 대한 Google 권장 HA 접근 방식이 아닙니다. logical replication은 일반적으로 asynchronous이므로 RPO = 0을 보장하기 어렵습니다. 또한 manual failover는 탐지, 의사결정, cutover 단계로 인해 3분 RTO를 초과할 위험이 있습니다. 이 옵션은 managed HA보다 오류 가능성이 더 큽니다.

cross-region read replica는 동일한 region 내 zonal outage가 아니라 regional outage를 위한 disaster recovery 전략에 가깝습니다. Cloud SQL의 read replicas는 asynchronous이므로 RPO = 0을 보장할 수 없습니다. 또한 promotion은 수동/운영 작업이며 3분 RTO를 일관되게 충족하지 못할 수 있습니다. 요구사항을 넘어서는 cross-region 비용과 복잡성도 추가됩니다.

Cloud SQL High Availability (regional)는 zonal resilience를 위한 관리형 권장 솔루션입니다. 동일한 region 내 다른 zone에 synchronous standby를 사용하여 커밋된 트랜잭션에 대해 RPO = 0을 가능하게 합니다. Automatic failover는 중단을 최소화하며 단일 zone 장애 시 엄격한 RTO 목표(수 분)를 충족하도록 설계되었습니다. 이는 요구사항과 모범 사례에 직접적으로 부합합니다.

문제 분석

핵심 개념: 이 문제는 zonal resilience를 위한 Cloud SQL for PostgreSQL 고가용성 설계를 테스트하며, 특히 엄격한 복구 목표인 RTO ≤ 3분 및 RPO = 0을 충족해야 합니다. Google Cloud에서 한 region 내 단일 zone 장애를 허용하기 위한 권장 패턴은 Cloud SQL High Availability (HA)이며, regional instance라고도 합니다. 정답이 맞는 이유: Cloud SQL for PostgreSQL HA (regional) instance는 동일한 region의 한 zone에 primary를, 다른 zone에 standby를 synchronous replication으로 프로비저닝합니다. replication이 synchronous이므로, 커밋된 트랜잭션은 acknowledgement 전에 두 zone 모두에 내구적으로 기록되며, 이것이 RPO = 0의 핵심 요구사항입니다. zonal failure 동안 Cloud SQL은 standby로 automatic failover를 수행하며, 일반적으로 수 분 내에 이루어져 수동 방식보다 RTO 3분 요구사항에 훨씬 더 잘 부합합니다. 이는 Cloud SQL의 zonal fault tolerance에 대한 Google 권장 모범 사례입니다. 주요 기능 / 구성: - instance 생성 시 “High availability (regional)”을 선택합니다. - standby는 동일한 region 내 다른 zone에 위치하며, 이는 요구사항(대상 region에서 단일 zone 장애)에 부합합니다. - Synchronous replication은 커밋된 트랜잭션에 대해 zero data loss를 가능하게 합니다. - Automatic failover는 운영 부담을 줄이고 RTO 예측 가능성을 개선합니다. - logical corruption/user error에 대한 보호를 위해 backups 및 (선택적으로) PITR을 함께 사용합니다(HA만으로는 이를 해결하지 못함). 흔한 오해: 많은 사람들이 read replicas(asynchronous)를 HA와 혼동합니다. read replicas는 주로 read 확장과 DR 패턴을 위한 것이며, promotion은 수동/운영적으로 복잡합니다. asynchronous replication은 RPO = 0을 보장할 수 없습니다. backups는 필수이지만 HA 메커니즘이 아니며 3분 RTO를 충족할 수 없습니다. 커스텀 CDC/logical replication 파이프라인은 복잡성을 추가하고, 빠르고 자동화된 failover와 함께 synchronous, zero-loss 동작을 보장하기도 일반적으로 어렵습니다. 시험 팁: 요구사항을 Cloud SQL 기능에 매핑하세요: - RPO = 0 + in-region에서 zonal outage 허용 => synchronous standby를 사용하는 Cloud SQL HA (regional). - Cross-region replicas는 regional disaster를 위한 것이며 보통 RPO가 0이 아닙니다. - Backups/PITR은 availability가 아니라 data recovery를 다룹니다. 명시적으로 요구되지 않는 한, 맞춤형 replication보다 managed HA와 automated failover로 reliability를 설계하라는 Google Cloud Architecture Framework 원칙을 사용하세요.

3
문제 3

Your edtech platform uses Cloud Firestore for storage and serves a React web app to a global audience. Each day at 00:00 UTC, you publish the same Top 20 practice tips (20 documents, ~5 KB each; total payload ~100 KB) to approximately 5 million daily active users across North America, Europe, and APAC. You need to cut Firestore read costs and achieve sub-150 ms p95 load times for this daily list while the content remains identical for 24 hours. What should you do?

serializable isolation(또는 더 강한 일관성 시맨틱)을 활성화하는 것은 비용이나 지연 시간이 아니라 동시성 하에서의 정확성을 목표로 합니다. Firestore는 native mode에서 문서 read와 쿼리에 대해 이미 strong consistency를 제공합니다. 더 엄격한 트랜잭션 패턴을 추가해도 read 수는 줄지 않으며, 지연 시간과 경합을 증가시킬 수 있습니다. 이 선택지는 문제를 잘못 이해한 것입니다. 병목은 결과 불일치가 아니라 동일 콘텐츠에 대한 반복적인 전 세계 read입니다.

US multi-region으로 이동하면 북미의 가용성과 지연 시간은 개선될 수 있지만, CDN 엣지에서 제공하는 것과 비교하면 Europe/APAC의 p95 지연 시간이 악화되거나 유의미하게 개선되지 않을 수 있습니다. 더 중요한 점은 Firestore read 비용을 줄이지 못한다는 것입니다. 각 사용자는 여전히 매일 20개 문서에 대한 read를 트리거합니다. 동일 페이로드가 수백만 번 요청될 때 multi-region 배치는 캐싱을 대체할 수 없습니다.

Firestore bundle을 사용하면 정확히 20개 문서를 사전 생성하여 정적 파일로 제공할 수 있습니다. Hosting + Cloud CDN은 24시간 TTL로 전 세계 엣지 로케이션에 bundle을 캐싱하여 저지연으로 전달하고 Firestore에서 트래픽을 오프로딩합니다. 이는 과금되는 Firestore read를 직접 줄이고, 대부분의 요청이 데이터베이스를 치는 대신 가까운 CDN POP에서 제공되므로 p95 로드 시간을 개선합니다.

publish_date에 대한 composite index는 특정 filter/order 조합에서 쿼리 실행 효율을 높이고 쿼리 실패를 방지할 수 있지만, 반환된 문서 read에 대한 Firestore 과금은 바꾸지 못하며 500만 사용자에 대한 전 세계 지연 시간 문제도 해결하지 못합니다. 쿼리는 어떤 경우든 동일한 20개 문서를 반환합니다. indexing은 반복 read를 제거하거나 엣지 캐싱 이점을 제공하지 못합니다.

문제 분석

핵심 개념: 이 문제는 전 세계에 분산된, 읽기 비중이 높고 하루 동안 동일한 콘텐츠에 대해 Cloud Firestore 읽기 비용과 지연 시간을 줄이는 방법을 평가합니다. 핵심 패턴은 사용자별 데이터베이스 읽기를 피하기 위해 (24시간 동안) 변경되지 않는 콘텐츠를 엣지에서 사전 계산하고 캐싱하는 것입니다. 정답이 맞는 이유: Firestore bundle을 사용하면 알려진 문서 집합(Top 20 tips)을 정적 아티팩트로 내보내 클라이언트가 Firestore 문서 읽기를 발생시키지 않고 로드할 수 있습니다. Firebase Hosting을 Cloud CDN 앞단에 두고 해당 bundle을 제공하면 트래픽이 Firestore에서 CDN 엣지 캐시로 이동합니다. 24시간 TTL을 적용하면 하루 500만 사용자 대부분이 가까운 엣지 로케이션에서 제공받아 전 세계 p95 150ms 미만을 달성하는 동시에 Firestore read 작업(따라서 비용)을 크게 줄일 수 있습니다. Firestore는 여전히 system of record이지만, 일일 목록은 캐시 가능한 정적 자산이 됩니다. 주요 기능 / 모범 사례: - Firestore Bundles: 문서/쿼리를 파일로 패키징하여 클라이언트 SDK가 로드할 수 있게 하고, 로컬 캐시를 채워 해당 문서에 대한 네트워크 read를 피합니다. - Firebase Hosting + Cloud CDN: 전 세계 엣지 캐싱, HTTP 캐싱 헤더, 소형 페이로드(~100 KB)에 대한 저지연 전송. - Cache control: 24시간 콘텐츠 윈도우에 맞춰 Cache-Control max-age=86400(그리고 선택적으로 immutable)을 설정하고, 캐시를 깔끔하게 갱신하기 위해 00:00 UTC에 새 bundle을 게시(종종 버전이 포함된 파일명 사용)합니다. - Architecture Framework 정렬: 반복적인 read를 엣지 캐싱으로 오프로딩하여 성능 효율성과 비용 최적화를 개선합니다. 흔한 오해: - 더 강한 일관성(serializable isolation)은 read나 지연 시간을 줄이지 않으며, 오버헤드를 증가시킬 수 있습니다. - Firestore를 다른 multi-region으로 옮기면 일부 사용자에게는 도움이 될 수 있지만, 근본적인 비용 요인(동일 데이터에 대한 수백만 번의 반복 read)을 제거하지는 못합니다. - Indexing은 쿼리 성능에 도움이 되지만, 문서 read 과금이나 전 세계 엣지 지연 시간을 줄이지는 못합니다. 시험 팁: 콘텐츠가 많은 사용자에게 동일하고 예측 가능한 일정으로 변경된다면, 데이터베이스 read보다 CDN/엣지 캐싱 또는 정적 전달을 우선 고려하세요. Firestore의 경우 특히 bundle이 사전 로딩과 read 비용 절감을 위해 설계되었고, Hosting+CDN이 웹 자산의 표준 전 세계 배포 메커니즘이라는 점을 기억하세요.

4
문제 4
(2개 선택)

Your travel-tech company operates a globally distributed seat allocation platform on Cloud Spanner with 3 read-write and 6 read-only regions; after importing 12 million seat and route records from a partner, you observe write latency spikes and CPU hotspots on 2 of 8 leader replicas, and Cloud Monitoring shows hot ranges on a table keyed by a monotonically increasing ticket_id and a composite key (route_id, class) where class has only 3 distinct values; at peak 35,000 writes/second, 70% of writes concentrate in a narrow key range; to follow Google-recommended schema design practices and avoid hotspots without sacrificing strong consistency or availability, what should you do? (Choose two.)

오답입니다. Auto-incrementing(단조 증가) primary keys는 높은 write rates에서 Cloud Spanner의 알려진 안티패턴입니다. 새 row가 키스페이스의 동일한 “끝”에 쌓이기 때문에, 소수의 range와 그 leader에 쓰기가 집중되어 CPU 핫스팟과 latency 스파이크가 발생합니다. Spanner가 ranges를 split할 수는 있지만, 최신 키는 여전히 가장 뜨거운 range를 타겟팅하므로 병목이 지속됩니다.

오답입니다. Normalization은 데이터를 테이블 간에 모델링하는 방식을 바꾸어 데이터 무결성을 돕고 중복을 줄일 수 있지만, 좋지 않은 primary key 분산으로 인해 발생하는 hot ranges를 직접적으로 해결하지는 않습니다. Primary keys가 여전히 sequential이거나 low-cardinality-leading이면, 동일한 leader와 range가 여전히 대부분의 쓰기를 받게 됩니다. Spanner에서 핫스팟 완화는 주로 key design과 write distribution에 관한 문제입니다.

오답입니다. Low-cardinality 속성(예: 3개 값만 있는 class)을 composite primary key의 앞쪽으로 올리면, row가 소수의 큰 연속 key ranges로 군집되는 경향이 있습니다(예: 모든 “economy”가 함께). 쓰기가 많은 상황에서는 소수의 range/leader가 hot해질 가능성이 커집니다. Spanner에서는 선두 key columns가 locality를 결정하며 write load 분산에 매우 중요합니다.

정답입니다. 다중 속성 primary key에서 high-cardinality 속성을 앞쪽에 배치하면 정렬된 키스페이스 전반으로 분산이 개선되어, 더 많은 range와 leader replicas로 쓰기가 분산됩니다. (route_id, class) 예시에서 class는 3개 값만 가지므로 write distribution을 위한 선두 구분자로 두면 안 됩니다. 더 높은 cardinality 필드를 먼저 두는 것은 핫스팟을 피하기 위한 Spanner 스키마의 핵심 모범 사례입니다.

정답입니다. bit-reversed sequential value(또는 유사한 key transformation)를 사용하는 것은 unique하고 순차적으로 생성되는 identifier가 필요할 때 핫스팟을 피하기 위한 권장 기법입니다. Bit-reversal은 인접한 sequence numbers를 키스페이스 전반에 분산시켜, 여러 range와 leader에 insert를 분배하고 CPU 핫스팟과 write latency 스파이크를 줄입니다. 이는 write scalability를 개선하면서도 Spanner의 strong consistency와 availability를 유지합니다.

문제 분석

핵심 개념: 이 문제는 핫스팟을 방지하기 위한 Cloud Spanner 스키마 설계를 평가합니다. Spanner에서는 데이터가 정렬된 키 순서로 저장되고 “ranges”(tablets)로 분할됩니다. 쓰기는 대상 키 값이 포함된 range(들)에 집중됩니다. 많은 쓰기가 좁고 인접한 키 공간에 몰리면, 멀티 리전 구성에서도 소수의 split과 그 leader가 CPU/latency 병목이 될 수 있습니다. 정답이 맞는 이유: 두 가지 핫스팟 패턴이 설명됩니다: (1) 단조 증가하는 ticket_id primary key로 인해 모든 신규 insert가 키스페이스의 “끝”(최신 range)을 타겟팅하는 경우, (2) composite key (route_id, class)에서 class가 3개 값만 가지는 경우입니다. class가 앞쪽에 배치되거나(또는 locality를 좌우하도록) 하면, 3개의 큰 연속 파티션만 만들어져 쓰기가 집중됩니다. Google 권장 사항은 primary key의 선두 부분이 높은 cardinality와 좋은 분산을 갖도록 하는 것입니다. 따라서 다중 속성 primary key에서는 high-cardinality 속성을 앞쪽으로 올려야 합니다(D). 순차 ID를 논리적으로 정렬된 형태로 유지해야 한다면, bit-reversed sequential values(E) 같은 key transformation을 사용해 키스페이스 전반으로 insert를 분산시키면서도 uniqueness를 유지하고 효율적인 생성이 가능하게 합니다. 주요 기능 / 모범 사례: Spanner는 ranges를 자동으로 split하지만, sequential keys로 인해 발생하는 “단일 hot end”를 제거할 수는 없습니다. hot range를 계속 split할 수는 있어도, 쓰기 부하를 처리하는 단일 leader가 존재하므로 병목이 남습니다. Bit-reversal(또는 유사한 hashing/salting 패턴)은 쓰기를 여러 range와 leader로 분산합니다. Composite keys에서는 순서가 중요합니다. 가장 많은 distinct values(그리고 가장 좋은 write distribution)를 가진 속성을 먼저 두고, low-cardinality 필드는 뒤에 둡니다. 흔한 오해: Normalization(B)은 update anomalies나 저장 효율을 개선할 수 있지만, 본질적으로 key-range write concentration을 해결하지는 않습니다. Low-cardinality 속성을 승격(C)하면 보통 소수의 연속 range로 쓰기가 더 군집되어 핫스팟이 악화됩니다. Auto-incrementing keys(A)는 높은 write throughput에서 Spanner의 대표적인 안티패턴입니다. 시험 팁: “hot ranges”, “monotonically increasing”, “low cardinality”, “writes concentrated in a narrow key range”를 보면 primary key 설계와 key ordering을 떠올리세요. Spanner에서는 첫 번째 key parts가 locality를 지배합니다. high-cardinality 선두 키를 선택하고, 순차 식별자에는 bit-reversed sequences 같은 기법을 사용해 핫스팟 없이 strong consistency와 availability를 유지하면서 write scalability를 확보하세요.

5
문제 5

You are building a Pub/Sub–triggered service on Cloud Functions (2nd gen) in us-central1 that must connect to a Cloud SQL for PostgreSQL instance. Your security policy requires the database to accept connections only from workloads inside the prod-vpc VPC, with no public internet exposure. The function can scale up to 200 concurrent requests during peak load, and you need stable connection management. What should you do to meet the security and performance requirements?

오답입니다. external(public) IP를 사용하는 것은 firewall rule로 source range를 제한하더라도 “public internet 노출 없음” 요구사항을 위반합니다. 또한 Cloud Functions는 기본적으로 고정된 egress IP가 없어 firewall allowlisting이 취약합니다. Cloud SQL Auth Proxy는 IAM 기반 auth와 TLS에 도움이 되지만, 200 concurrent request에 대한 안정적인 connection 관리를 본질적으로 제공하지는 않습니다.

오답입니다. public IP는 여전히 database를 internet에 노출하므로 보안 정책과 충돌합니다. 또한 firewall rule로 Cloud Functions 트래픽만 허용하는 방식은 serverless egress IP가 추가 NAT/egress control 없이는 안정적이지 않기 때문에 문제가 됩니다. connection pooling은 성능에 좋지만, networking 모델이 “prod-vpc 내부에서만” 요구사항을 충족하지 못합니다.

networking 측면에서는 부분적으로 맞습니다: private IP + private services access + Serverless VPC Access는 올바른 private connectivity 패턴입니다. 그러나 주요 답으로 Cloud SQL Auth Proxy를 선택하는 것은 200 concurrent request에서 요구된 “안정적인 connection 관리”를 해결하지 못합니다. proxy는 pooling의 대체가 아니며, pooling이 없으면 PostgreSQL connection을 고갈시켜 성능이 저하될 수 있습니다.

정답입니다. private services access를 사용하는 Cloud SQL private IP는 인스턴스가 prod-vpc 내부에서만 도달 가능하도록 하고 public로 노출되지 않게 합니다. 동일 region의 Serverless VPC Access를 통해 Cloud Functions (2nd gen)이 해당 private IP에 접근할 수 있습니다. connection pool(및 선택적으로 PgBouncer 같은 pooling layer)을 사용하면 high concurrency에서 안정적인 connection 관리를 제공하여 connection storm을 방지하고, Cloud SQL connection limit 및 best practice에 부합합니다.

문제 분석

핵심 개념: 이 문제는 serverless(Cloud Functions 2nd gen)에서 Cloud SQL for PostgreSQL로의 안전한 private connectivity와, 안정적인 database connection을 유지하면서 높은 concurrency를 처리하는 방법을 평가합니다. 핵심 서비스는 private services access를 사용하는 Cloud SQL private IP, Serverless VPC Access, 그리고 애플리케이션 측 connection pooling입니다. 정답인 이유: 데이터베이스가 public internet 노출 없이 prod-vpc 내부의 워크로드에서만 connection을 허용해야 한다는 요구 사항은, Cloud SQL이 public IP 없이 private IP만 사용해야 함을 의미합니다. Cloud Functions (2nd gen)는 serverless이며 기본적으로 VPC에 직접 연결되지 않으므로, private resource로 트래픽을 라우팅하려면 동일한 region과 VPC에 있는 Serverless VPC Access connector를 사용해야 합니다. 성능 측면에서 200개의 동시 요청은 각 요청이 자체 connection을 열 경우 너무 많은 database session을 생성할 수 있으므로, connection을 제한하고 재사용하기 위해 connection pool이 필요합니다. Option D만이 private networking 요구 사항과 안정적인 connection 관리 요구 사항을 모두 충족합니다. 주요 기능: - Cloud SQL for PostgreSQL을 private IP 전용으로 구성하고, private services access를 사용하여 인스턴스가 prod-vpc에서 도달 가능한 internal address를 받도록 합니다. - us-central1의 Serverless VPC Access connector를 prod-vpc에 연결하여 Cloud Functions (2nd gen)가 private IP에 도달할 수 있도록 합니다. - 애플리케이션 수준의 connection pooling을 사용하여 전체 database connection 수를 제한하고, 급증하는 serverless concurrency 환경에서 재사용성을 향상시킵니다. - 표준 database authentication 및 IAM 제어는 계속 적용됩니다. private IP는 노출을 줄여주지만 최소 권한 액세스 설계를 대체하지는 않습니다. 흔한 오해: - firewall rule로 public IP를 제한하는 것은 public 노출을 제거하는 것과 같지 않습니다. public endpoint는 여전히 엄격한 no-internet-exposure 정책을 위반합니다. - Cloud SQL Auth Proxy는 authentication과 encrypted connectivity를 개선하지만, 높은 concurrency로 인해 발생하는 connection scaling 문제를 그 자체로 해결하지는 않습니다. - serverless 워크로드는 자동으로 VPC 내부에 존재하지 않으므로, private IP access에는 Serverless VPC Access connector가 필요합니다. 시험 팁: 문제에서 serverless가 private database에 도달해야 한다고 하면, Serverless VPC Access와 Cloud SQL private IP를 떠올리세요. 또한 높은 concurrency나 connection 안정성이 언급되면 connection pooling을 떠올리세요. 요구 사항이 internet 노출을 명시적으로 금지한다면 public IP를 완전히 제거하는 답안을 우선 선택하세요.

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

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

6
문제 6

Your healthcare analytics platform is closing its private data center and must move a 2-node Oracle RAC 19c OLTP cluster (24 TB) that uses ASM and SCAN listeners to Google Cloud. The application depends on RAC services with FAN/TAF-based failover and requires minimal to no code changes, while maintaining equivalent performance (~5 ms storage latency and >40,000 TPS) after migration. You need a supported landing zone that preserves the RAC architecture and existing Oracle licensing with the least rework. What should you do?

Cloud Spanner는 강한 일관성과 multi-region HA를 갖춘 cloud-native, 수평 확장형 relational database입니다. 그러나 Oracle RAC OLTP에서 Spanner로의 마이그레이션은 상당한 schema 및 애플리케이션 변경(SQL dialect 차이, data model 변경, transaction semantics 고려)을 필요로 합니다. 또한 Oracle RAC 서비스, ASM, SCAN, 또는 FAN/TAF 동작을 보존하지 않습니다. 이는 최소/무코드 변경 요구사항을 위반하며 “RAC 아키텍처 보존” landing zone이 아닙니다.

persistent disk 및 instance group을 사용하는 Compute Engine VM은 지원되는 Oracle RAC 배포에 적합하지 않습니다. RAC는 엄격하게 제어되는 cluster networking과 shared storage 동작에 의존하며, 범용 VM에서 RAC를 구축하면 supportability 제약에 부딪힐 수 있고 필요한 낮은 스토리지 지연과 높은 TPS를 일관되게 충족하지 못할 수 있습니다. instance group은 VM 가용성을 다루는 것이지, Oracle RAC의 cluster 시맨틱(SCAN, ASM, FAN/TAF)과 shared-disk 요구사항을 해결하지 못합니다.

Cloud SQL for PostgreSQL( Database Migration Service를 사용하더라도)은 Oracle에서 PostgreSQL로의 cross-engine 마이그레이션을 의미합니다. 이는 애플리케이션 및 SQL 변경, stored procedure, data type 재검증, 성능 튜닝을 필요로 하며 RAC 고유의 client failover 메커니즘(FAN/TAF)이나 Oracle 기능을 보존하지 못합니다. 또한 기존 Oracle 라이선스를 유지하고 최소 재작업으로 RAC 아키텍처를 보존해야 한다는 요구사항과도 충돌합니다.

Oracle용 Bare Metal Solution은 Oracle RAC를 포함한 Oracle 워크로드를 예측 가능한 성능과 지원되는 아키텍처로 전용 물리 서버에서 실행하도록 목적에 맞게 설계되었습니다. 이는 최소한의 애플리케이션 변경으로 Oracle RAC 기능(ASM, SCAN listener, FAN/TAF 기반 failover)을 유지할 수 있게 하며 BYOL licensing model을 지원합니다. Google Cloud에서 RAC를 보존하면서 엄격한 OLTP latency/TPS 요구사항을 충족해야 할 때 가장 적절한 landing zone입니다.

문제 분석

핵심 개념: 이 문제는 RAC 고유 기능(ASM, SCAN, FAN/TAF)을 유지해야 하고 애플리케이션 변경을 최소화하면서 기존 Oracle 라이선스를 계속 사용해야 하는, 고도로 특화되고 성능 민감한 Oracle RAC 워크로드에 대해 올바른 Google Cloud landing zone을 선택하는지를 평가합니다. 정답이 맞는 이유: Oracle용 Bare Metal Solution (BMS)은 Google 관리 시설의 전용 물리 서버에서 Oracle database(Oracle RAC 포함)를 실행하도록 특별히 설계된, 지원되는 Google Cloud 오퍼링이며 고객 VPC에 연결됩니다. 이는 RAC 아키텍처(다중 노드, BMS에서 RAC를 위해 구현된 공유 스토리지 시맨틱)를 보존하고, ASM 및 SCAN listener를 지원하며, database와 연결 모델이 Oracle RAC로 유지되므로 최소 또는 무코드 변경으로 동일한 client failover 패턴(FAN/TAF)을 가능하게 합니다. 또한 성능 요구사항에도 부합합니다. BMS는 고 TPS의 OLTP에 적합한 예측 가능하고 낮은 지연의 스토리지 및 네트워크 특성을 제공하여, 범용 가상화 플랫폼에서 마주칠 수 있는 변동성과 기능 격차를 피할 수 있습니다. 주요 기능 / Best Practices: - 지원되는 전용 호스트에서 Oracle RAC를 제공하여, 지원되지 않는 DIY RAC 구축을 회피합니다. - Oracle licensing model(일반적으로 BYOL)과 운영 툴링을 유지합니다. - VPC로의 네트워크 통합을 통해 앱에서의 private connectivity를 가능하게 합니다(Cloud Interconnect/VPN을 통한 hybrid 포함). - 마이그레이션 접근은 일반적으로 Oracle-native 방식(RMAN duplicate/restore, Data Guard, 또는 설계에 따라 storage 기반 방식)을 사용해 다운타임을 최소화합니다. - Google Cloud Architecture Framework 목표에 부합합니다: reliability(RAC HA), performance efficiency(전용 하드웨어), operational excellence(지원되는 reference architectures). 흔한 오해: 팀들은 종종 “Compute Engine으로 lift-and-shift”가 동등하다고 가정하지만, Oracle RAC는 shared storage, cluster interconnect, vendor support 측면에서 엄격한 요구사항이 있습니다. 마찬가지로 Spanner 또는 PostgreSQL로 modernizing하면 cloud-native HA가 개선될 수 있지만, 이는 “최소 또는 무코드 변경” 제약을 위반하며 Oracle 기능 동등성을 충족하지 못할 수 있습니다. 시험 팁: Oracle RAC + ASM + SCAN + FAN/TAF + 최소 변경 + 라이선스 유지 + 높은 OLTP 성능을 보면, Oracle용 Bare Metal Solution 쪽으로 강하게 기울이세요. Compute Engine은 단일 인스턴스 Oracle 또는 일부 HA 패턴에는 적합하지만, 시험 시나리오에서의 차별점은 RAC의 supportability와 성능 예측 가능성입니다.

7
문제 7

Your media-streaming platform runs an AlloyDB for PostgreSQL cluster in us-central1 that is accessible only via a private IP; compliance forbids opening a public endpoint or installing agents on database VMs, and you must continuously replicate a subset of 12 tables (about 1.8 TB total, up to 2,500 row changes per second) into BigQuery for analytics and ML with end-to-end latency under 10 seconds and 99.9% delivery reliability using Google-managed services that automatically handle schema changes and scale without downtime; what should you do?

AlloyDB를 polling하는 custom GKE 마이크로서비스는 CDC가 아니며, 2,500 changes/sec에서 <10s 지연 시간과 99.9% 전달 신뢰성을 달성하려면 상당한 커스텀 엔지니어링(중복 제거, 순서 보장, 재시도, backpressure, schema drift 처리)이 필요합니다. Polling은 소스 부하도 증가시키고 운영 복잡성이 큽니다. 또한 자동 확장과 다운타임 없는 스키마 변경 처리를 제공하는 Google 관리형 서비스를 사용해야 한다는 요구를 위반합니다.

BigQuery federated queries(external connections 사용)는 데이터를 제자리에서 조회하기 위한 것이지, BigQuery로 지속적으로 복제하는 것이 아닙니다. 일반적으로 downstream analytics/ML을 위해 BigQuery 테이블로 end-to-end 10초 미만 지연 시간으로 변경을 전달해야 한다는 요구를 충족하지 못하며, 높은 변경률에서 성능/비용이 예측 불가능할 수 있습니다. 또한 복제 데이터에 대해 99.9% 전달 신뢰성을 보장하는 내구성 있는 전달 파이프라인을 제공하지 않습니다.

Database Migration Service는 데이터베이스 간 마이그레이션과 지속적 복제를 위해 설계되었습니다(예: on-prem/MySQL/PostgreSQL에서 Cloud SQL/AlloyDB로). BigQuery를 타깃으로 직접 CDC를 스트리밍하는 표준 관리형 서비스가 아닙니다. 설령 다른 곳에 데이터를 staging할 수 있더라도 구성 요소와 지연 시간이 추가되며, 자동 스키마 변경 처리 요구와 BigQuery로의 직접적/확장 가능/관리형 경로 요구에 부합하지 않습니다.

Datastream은 VM 에이전트를 설치하지 않고 log 기반 replication을 사용해 AlloyDB 같은 PostgreSQL 호환 소스에서 변경을 캡처하는 관리형 CDC 서비스입니다. 프라이빗 연결을 지원하므로 소스를 private-only로 유지할 수 있습니다. Datastream을 Google 제공 Dataflow template과 결합해 BigQuery로 스트리밍하면 autoscaling, checkpointing, 강력한 retry 시맨틱을 제공하여 낮은 지연 시간(<10s) ingestion과 높은 전달 신뢰성을 달성할 수 있으며, 관리형 방식으로 스키마 진화 처리도 지원합니다.

문제 분석

핵심 개념: 이 문제는 프라이빗 AlloyDB for PostgreSQL 소스에서 BigQuery로 거의 실시간 change data capture(CDC)를 수행하는 능력을 평가합니다. 완전 관리형 Google 서비스를 사용하면서 낮은 지연 시간, 높은 신뢰성, 자동 확장, 그리고 스키마 진화에 대한 복원력을 요구합니다. 정답이 맞는 이유: Datastream은 데이터베이스(예: AlloyDB 같은 PostgreSQL 호환 소스 포함)를 위한 Google의 관리형 CDC 서비스입니다. Datastream은 지속적인 row-level 변경을 캡처하고 낮은 지연 시간으로 스트리밍할 수 있습니다. AlloyDB 클러스터가 private-only이고 데이터베이스 VM에 에이전트를 설치할 수 없으므로, Datastream이 적합합니다. Datastream은 호스트 에이전트가 아니라 데이터베이스 네이티브 replication/log 기반 메커니즘을 사용하기 때문입니다. Datastream은 프라이빗 연결 패턴(구성에 따라 VPC connectivity/Private Service Connect 등)을 지원하므로 트래픽을 private IP 경로로 유지할 수 있습니다. 변경 사항을 BigQuery에 end-to-end <10s 지연 시간과 99.9% 전달 신뢰성으로 적재하려면, 권장 패턴은 Datastream CDC를 Google 제공 Datastream-to-BigQuery Dataflow template을 사용하는 streaming pipeline으로 연결하는 것입니다. Dataflow는 autoscaling, checkpointing, 그리고 exactly-once/at-least-once 처리 시맨틱(싱크 동작에 따라)을 제공하여 높은 전달 신뢰성과 다운타임 없는 지속 운영을 가능하게 합니다. 주요 기능 / 구성 / 모범 사례: - 12개 필수 테이블에 대한 include list(부분 복제)를 사용하여 PostgreSQL CDC용 Datastream을 구성합니다. - private connectivity(퍼블릭 엔드포인트 없음)와 최소 권한의 데이터베이스 replication user를 사용합니다. - Datastream-to-BigQuery Dataflow template을 사용해 지속적 ingestion, 확장, 운영 관리를 처리합니다. - 스키마 진화 처리 활성화: Datastream은 DDL 변경을 캡처하며 template/pipeline이(지원되는 변경 유형 범위 내에서) BigQuery로 스키마 업데이트를 전파할 수 있어 수동 개입을 줄입니다. - Google Cloud Architecture Framework에 따라 신뢰성을 설계합니다: 리전 리소스를 적절히 사용하고, lag/throughput을 모니터링하며, 알림을 설정하고, 2,500 changes/sec 및 1.8 TB 초기 상태에 대해 quota(BigQuery streaming inserts, Dataflow worker limits, Datastream throughput)를 계획합니다. 흔한 오해: - “Federated queries”는 더 단순해 보이지만, 데이터를 복제하지 않으며 대규모에서 sub-10-second 분석 최신성 요구를 충족하지 못합니다. - “DMS가 BigQuery로 복제할 수 있다”는 흔한 혼동입니다: DMS는 database-to-database 마이그레이션/복제(예: Cloud SQL/AlloyDB로)를 위한 것이지, BigQuery로의 지속적 CDC를 주 타깃으로 하는 서비스가 아닙니다. - “Custom polling service”는 유연해 보이지만 관리형 서비스/확장/신뢰성 요구를 위반하며, 보통 낮은 지연 시간 CDC를 무거운 엔지니어링 없이 달성하기 어렵습니다. 시험 팁: private-only 소스, 에이전트 불가, 지속적 CDC, BigQuery 타깃, 낮은 지연 시간, 관리형 스키마 변경 처리가 보이면—Datastream + Dataflow template to BigQuery를 떠올리세요. DMS는 분석용 BigQuery ingestion이 아니라 운영 DB 간 마이그레이션에 사용하세요.

8
문제 8

Your company runs a global event-ticketing platform on Google Cloud. Your engineering team is building a real-time seat reservation service that must prevent double-booking via strongly consistent, durable writes and elastically scale with live traffic spikes. The system must sustain up to 120,000 write operations per second at peak, keep p95 write latency under 15 ms, and incur less than 5 minutes of unplanned downtime per month (99.99% availability). You need a primary data store with very low-latency, high write throughput, and a 99.99% uptime SLA for production. What should you do?

Cloud SQL(MySQL/PostgreSQL/SQL Server)은 strong consistency와 ACID transactions를 제공하지만, 주로 vertical scaling에 의존하며 상당한 sharding과 운영 복잡성 없이 지속적으로 120,000 writes/sec에서 p95 <15 ms를 달성하는 데 실질적인 한계가 있습니다. High availability는 가능하지만, 이 write rate에서 elastic한 스파이크 처리와 함께 99.99%를 충족하는 것은 일반적인 강점 영역이 아닙니다. 중간 수준의 확장 요구가 있는 regional OLTP workload에 더 적합합니다.

Cloud Spanner는 strongly consistent하고 horizontally scalable한 relational workload를 위해 목적에 맞게 설계되었습니다. 이중 예약을 방지하기 위한 ACID transactions를 지원하고, nodes/processing units를 추가하여 write throughput을 확장하며, multi-region 구성에서 99.99% SLA를 제공합니다. hotspots를 피하기 위한 적절한 schema/key design과 애플리케이션 compute의 colocated 배치를 통해, Spanner는 durable한 system of record로서 높은 throughput에서 낮은 write latency를 달성할 수 있습니다.

Memorystore(Redis/Memcached)는 low latency에 최적화된 in-memory cache/data store로, primary durable database of record가 아닙니다. Redis가 atomic operations를 지원할 수는 있지만, 미션 크리티컬한 예약 ledger에 기대되는 동일한 durability, multi-region relational transactional guarantees, 또는 99.99% SLA 특성을 제공하지는 않습니다. 일반적으로 seat maps, sessions, 또는 rate limits를 캐시하는 데 사용되며, authoritative booking store로는 사용하지 않습니다.

Cloud Bigtable은 wide-column/key-value workload에 대해 매우 높은 throughput과 low latency를 제공하며 대규모로 확장할 수 있습니다. 그러나 relational database가 아니며, 엄격한 좌석 예약 semantics(다중 엔티티 제약으로 이중 예약 방지)에 필요한 방식의 rows 간 full ACID transactions를 제공하지 않습니다. Bigtable은 event streams, time-series, 그리고 대규모 analytics serving에는 훌륭하지만, 기본 transactional reservation database로는 이상적이지 않습니다.

문제 분석

핵심 개념: 이 문제는 (1) 이중 예약을 방지하기 위한 strong consistency, (2) 낮은 latency로 매우 높은 write throughput, (3) 스파이크 동안의 elastic scaling, (4) 99.99% availability SLA를 제공할 수 있는 기본 운영 데이터베이스를 선택하는지를 테스트합니다. Google Cloud에서 이 조합은 가장 직접적으로 Cloud Spanner에 해당합니다. 정답이 맞는 이유: Cloud Spanner는 horizontal scale을 위해 설계된 globally distributed, strongly consistent relational database입니다. 좌석 예약은 두 사용자가 동일한 좌석을 예약하지 못하도록 ACID semantics(예: conditional updates, unique constraints, serializable isolation)가 필요한 전형적인 transactional workload입니다. Spanner는 strongly consistent하고 durable한 writes를 제공하며, 노드를 추가하여 write throughput을 확장할 수 있습니다. 또한 multi-region 구성에 대해 99.99% SLA를 제공하여 월 <5분 downtime 요구사항과 부합합니다. 주요 기능 / Best Practices: - Strong consistency + ACID transactions: 좌석 hold/confirmation에 read-write transactions를 사용하고, primary keys/unique indexes로 uniqueness를 강제합니다. - Horizontal scaling: nodes/processing units로 용량을 산정하며, Spanner는 애플리케이션 레이어에서 sharding 없이 reads/writes를 확장합니다. - Low latency at scale: compute를 Spanner instance 가까이에 배치하고, availability를 위해 multi-region을 사용하거나 단일 region latency를 더 낮추기 위한 tradeoff로 regional을 사용합니다. - Availability: multi-region instance configuration(예: nam* 또는 eur*)을 사용하고, hotspots를 피하기 위한 schema design best practices를 따릅니다(예: monotonically increasing keys를 피하고 hashed/UUID keys 또는 key salting 사용). - Architecture Framework 정렬: Reliability(multi-region, automated replication), Performance(scale-out writes), Operational Excellence(managed service, online schema changes). 흔한 오해: Bigtable은 massive write throughput과 low latency를 처리할 수 있지만, relational/ACID transactional database가 아니며 rows/entities 전반에서 이중 예약을 방지하는 데 필요한 동일한 strong transactional guarantees를 제공하지 않습니다. Memorystore는 in-memory이며 durable한 system of record가 아닙니다. Cloud SQL은 strong consistency를 제공하지만, 일반적으로 복잡한 sharding 없이 120k writes/sec에서 p95 <15 ms로 elastic하게 확장하기 어렵고, 99.99% SLA 요구사항을 동일한 방식으로 충족하지 못할 수 있습니다. Exam Tips: “prevent double-booking,” “strongly consistent durable writes,” “global,” “elastic scale,” “99.99% SLA”를 보면 Cloud Spanner를 떠올리세요. relational transactions 없이 매우 높은 throughput의 key-value/time-series라면 Bigtable을, caching이라면 Memorystore를, vertical scaling과 read replicas 중심의 전통적 relational workload라면 Cloud SQL을 떠올리세요.

9
문제 9

You operate a real-time sports ticketing platform that uses Cloud SQL for MySQL in asia-northeast1. At 10:12 JST on a weekday launch, the instance entered an automatic maintenance event that caused 6 minutes of downtime, impacting over 15,000 concurrent users. Your SLO requires that any maintenance occur only outside your peak window of 09:00–22:00 JST, and you must make an immediate configuration change without migrating platforms or adding new components. What should you do to prevent future maintenance from occurring during peak hours?

정답입니다. Cloud SQL 인스턴스 maintenance window를 비업무 시간대로 구성하는 것은 피크 시간에 유지보수가 발생할 가능성을 줄이기 위한 의도된 제어입니다. 주간 요일/시간 window를 선택하고(설정 시 JST를 UTC로 변환) Google이 해당 window 내에서 적용 가능한 유지보수를 스케줄링하도록 합니다. 이는 즉시 가능한 구성 변경이며, 구성 요소 추가나 migration을 하지 말라는 제약을 충족합니다.

오답입니다. Cloud Spanner로의 migration은 플랫폼 변경이며 상당한 migration 작업(스키마 변경, 애플리케이션 변경, 데이터 migration, 비용 모델 차이)을 수반합니다. 문제는 플랫폼 migration이나 새 구성 요소 추가를 명시적으로 금지합니다. 또한 fully managed 서비스에도 운영 이벤트는 존재하며, 핵심은 허용된 가장 단순한 변경으로 명시된 요구사항을 충족하는 것입니다.

오답입니다. Support 케이스를 열면 downtime이 기대를 초과한 이유를 설명받는 데는 도움이 될 수 있지만, 09:00–22:00 JST 외 시간에 유지보수가 수행되도록 보장하는 예방적 제어를 구현하지는 못합니다. 요구사항은 향후 피크 시간 유지보수를 방지하기 위한 즉시 구성 변경입니다. Support는 사후 대응이며 유지보수 window를 스케줄링하는 구성 메커니즘이 아닙니다.

오답입니다. Cloud Scheduler는 Cloud SQL maintenance window를 “강제”하거나 Google-managed maintenance를 5분으로 제한할 수 없습니다. 유지보수 duration은 외부 scheduler로 상한을 둘 수 있는 대상이 아니며, Cloud SQL 유지보수는 job 트리거가 아니라 Cloud SQL 설정(maintenance window/track)으로 제어됩니다. 이 선택지는 Cloud SQL 유지보수의 managed 특성을 오해하고 있습니다.

문제 분석

핵심 개념: 이 문제는 계획된 유지보수를 위한 Cloud SQL 운영 제어, 특히 가용성 목표에 맞추기 위해 Cloud SQL maintenance window를 구성하는 것을 평가합니다. Cloud SQL for MySQL에서는 Google이 주기적으로 유지보수(패치 적용, 마이너 버전 업데이트, 인프라 작업)를 수행합니다. 일부 유지보수는 특히 단일 존 인스턴스이거나 failover/replica promotion이 관련될 때 짧은 downtime을 유발할 수 있습니다. 정답이 맞는 이유: SLO는 09:00–22:00 JST 외 시간에만 유지보수가 수행되어야 하며, 플랫폼 migration이나 구성 요소 추가 없이 즉시 구성 변경을 해야 합니다. 직접적이고 지원되는 제어는 인스턴스의 maintenance window를 비피크 시간대(예: 일요일 01:00–03:00 JST)로 설정하는 것입니다. 그러면 Cloud SQL은 해당 window 내에서(최선의 노력으로) 적용 가능한 유지보수를 스케줄링하여, 피크 시간에 유지보수가 시작될 위험을 크게 줄입니다. 이것이 바로 maintenance window 기능이 설계된 목적입니다. 주요 기능 / Best Practices: - Cloud SQL maintenance window: 요일과 시간(구성에서는 UTC 기준이며, JST에서 UTC로 올바르게 변환해야 함)을 선택합니다. 또한 위험 허용도에 따라 maintenance track(preview vs stable) 설정도 고려하세요. - Google Cloud Architecture Framework (Reliability)와 정렬: 운영 이벤트를 계획하고, 통제된 maintenance window를 사용하며, graceful degradation을 위해 설계합니다. HA (regional)는 downtime을 줄일 수 있지만, 문제에서 구성 요소 추가를 금지합니다. - 운영 세부사항: maintenance window는 모든 이벤트에 대해 엄격한 보장을 제공하지는 않지만, 아키텍처 변경 없이 사용할 수 있는 주요 제어 수단입니다. 흔한 오해: - “데이터베이스를 바꿔서” (Spanner) 유지보수를 피한다는 것은 migration이며 제약을 위반합니다. - “Support가 downtime을 설명해줄 수 있다”는 것은 피크 시간 재발을 방지하지 못합니다. - “Cloud Scheduler가 유지보수 시간을 강제할 수 있다”는 것은 Cloud SQL 유지보수 방식이 아닙니다. Google-managed maintenance를 5분으로 programmatically 제한할 수 없습니다. Exam Tips: 문제가 업무 시간 중 Cloud SQL 유지보수를 방지하라고 하면서 migration이나 새 구성 요소를 제한한다면, 기대되는 답은 Cloud SQL maintenance window(그리고 선택적으로 maintenance track) 구성입니다. maintenance window를 넘어서는 가용성이 필요하다면 HA (regional), read replicas, 애플리케이션 레벨 retries를 고려하되, 문제에서 아키텍처 변경을 허용하는 경우에만 적용하세요.

10
문제 10

You are designing a global order reconciliation service for a multinational retail platform. Applications in North America, Europe, and Asia must be able to read and write concurrently, with p95 cross-region transaction commit latency under 200 ms. The database must be fully managed, relational (ANSI SQL), provide global external consistency with RPO=0, support online schema changes, and meet a 99.99% availability target. Which Google Cloud service should you choose?

Bigtable은 매우 높은 처리량과 저지연 key/value 접근(time-series, IoT, analytics serving)에 최적화된 완전 관리형 wide-column NoSQL 데이터베이스입니다. ANSI SQL 관계형이 아니며, Spanner와 같은 전 세계 외부 일관성 기반의 멀티 리전 트랜잭션 시맨틱을 제공하지 않습니다. 가용성을 위해 복제할 수는 있지만, 엄격한 일관성과 온라인 관계형 스키마 진화 요구사항을 갖는 리전 간 ACID 트랜잭션에는 적합하지 않습니다.

Firestore는 강력한 일관성과 멀티 리전 복제 옵션을 갖춘 완전 관리형 문서 데이터베이스이며, 글로벌 애플리케이션을 지원할 수 있습니다. 그러나 관계형 ANSI SQL 데이터베이스가 아니고, 관계형으로 설명된 주문 정산 시스템에서 기대되는 관계형 스키마, 조인, SQL 트랜잭션 모델을 제공하지 않습니다. 또한 Spanner를 가리키는 전형적인 “external consistency + SQL + global transactions” 요구사항과도 일치하지 않습니다.

Cloud SQL for MySQL은 관리형 관계형 데이터베이스이지만, 기본적으로 리전 단위입니다. 리전 간 설계는 일반적으로 read replica와 비동기 복제에 의존하므로 RPO=0을 보장할 수 없습니다. 동시 멀티 리전 쓰기와 global external consistency를 달성하는 것은 Cloud SQL의 기능이 아닙니다. 장애 조치 시 primary가 변경되며, 복제 모드에 따라 운영 복잡성과 잠재적 데이터 손실이 발생할 수 있습니다. active-active 쓰기로 전 세계 99.99%를 달성하는 것은 이 서비스의 목표 사용 사례가 아닙니다.

Cloud Spanner는 모든 요구사항을 직접 충족하는 유일한 Google Cloud 데이터베이스입니다: 완전 관리형, ANSI SQL을 지원하는 관계형, global external consistency(true serializability), RPO=0을 위한 동기식 복제, 그리고 99.99% 가용성을 위해 설계된 멀티 리전 구성. 여러 리전에서의 동시 읽기/쓰기를 지원하며 온라인 스키마 변경을 제공합니다. 주문 처리 및 정산(reconciliation)과 같은 글로벌 트랜잭션 시스템을 위해 목적에 맞게 설계되었습니다.

문제 분석

핵심 개념: 이 문제는 동시 다중 리전 읽기/쓰기를 강력한 일관성(외부 일관성, external consistency)으로 지원하고, 데이터 손실이 0(RPO=0)이며, 매우 높은 가용성을 제공하는 완전 관리형 전 세계 분산 관계형 데이터베이스를 선택하는지를 평가합니다. 정답이 맞는 이유: Cloud Spanner는 Google Cloud의 전 세계 분산, 수평 확장 가능한 ANSI SQL 관계형 데이터베이스로, 멀티 리전 active-active 워크로드를 위해 설계되었습니다. 리전 간 트랜잭션에 대해 외부 일관성(true serializability)을 제공하는데, 이것이 “global external consistency with RPO=0” 요구사항의 핵심입니다. Spanner에서는 멀티 리전 구성에서 커밋이 복제본들에 동기식으로 복제되므로, 커밋이 승인(acknowledged)되면 한 리전이 장애가 나더라도 내구성이 보장됩니다(RPO=0). 또한 Spanner는 완전 관리형이며 온라인 스키마 변경을 지원하여 운영 요구사항에도 부합합니다. 주요 기능 / 구성 / 모범 사례: - 멀티 리전 인스턴스 구성(예: nam3, eur3, asia1)은 지리적으로 분리된 리전 간 고가용성과 동기식 복제를 제공합니다. 적절히 구성하면 99.99% 가용성 목표를 지원합니다. - 외부 일관성은 Spanner의 TrueTime 기반 동시성 제어로 구현되어, 전 세계적으로 일관된 읽기와 쓰기를 보장합니다. - ANSI SQL 및 관계형 모델링이 핵심 기능이며, 보조 인덱스와 트랜잭션을 포함합니다. - 온라인 스키마 변경은 다운타임 없이 많은 스키마 업데이트를 가능하게 합니다(글로벌 리테일 플랫폼에 중요). - 지연 시간: 리전 간 커밋 지연은 복제본 배치와 네트워크 거리의 영향을 받습니다. 강력한 일관성으로 리전 간 트랜잭션이 반드시 필요할 때 Spanner가 의도된 서비스입니다. 실제로는 p95 목표를 맞추기 위해 인스턴스 구성과 애플리케이션 접근 패턴(예: locality, leader placement)을 설계합니다. 흔한 오해: Firestore는 멀티 리전이며 강력한 일관성을 제공하지만, NoSQL 문서 데이터베이스로서 ANSI SQL 관계형이 아닙니다. Cloud SQL은 관계형이지만, 대륙 간 외부 일관성과 RPO=0을 만족하는 글로벌 active-active 쓰기를 위해 설계되지 않았습니다. 리전 간 복제는 일반적으로 비동기이며, 장애 조치 시 primary가 변경됩니다. Bigtable은 wide-column NoSQL로, 관계형 SQL 트랜잭션이나 리전 간 외부 일관성을 제공하지 않습니다. 시험 팁: “global”, “concurrent writes in multiple regions”, “ANSI SQL”, “external consistency”, “RPO=0”가 보이면 기본적으로 Cloud Spanner를 선택하세요. 대신 PostgreSQL/MySQL 호환성과 read replica 및 리전 HA를 강조하면 Cloud SQL을, 문서 데이터와 오프라인 동기화를 강조하면 Firestore를, 대규모 처리량의 key-value/time-series를 강조하면 Bigtable을 떠올리세요.

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

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

11
문제 11

A global event ticketing platform runs its reservation and seat-allocation system on Cloud SQL for PostgreSQL 14; your SLOs require RTO ≤ 5 minutes and RPO ≤ 5 minutes, you must tolerate a single-zone outage with zero data loss and also be able to recover from a regional outage within minutes, and you need to choose a high-availability and disaster-recovery topology that meets these constraints without changing the application.

cross-region read replica는 asynchronous replication을 사용하므로 primary failure 동안 zero data loss를 보장할 수 없습니다(RPO는 lag에 따라 0보다 클 수 있음). 또한 cross-region replica만 두는 것은 단일 zone outage를 zero data loss로 허용하고 빠른 automatic failover를 제공해야 한다는 요구사항을 충족하지 못합니다. primary region 내 HA(multi-zone synchronous standby)가 여전히 필요합니다. 이 옵션은 DR에 초점을 맞추지만 HA와 zero-data-loss zonal 요구사항을 놓칩니다.

synchronous failover replica(HA)는 다른 zone에 있어야 하지만, 모든 것을 한 region 내에만 두면 regional outage를 수 분 내에 복구해야 한다는 요구사항을 충족하지 못합니다. 같은 region의 HA는 zonal failure를 보호할 뿐 regional disaster에는 대응하지 못합니다. replica를 여러 개 추가하더라도 region-wide outage는 primary와 모든 same-region replica를 함께 중단시키므로 DR 요구사항을 위반합니다.

이는 Cloud SQL best practice와 일치합니다: zero-data-loss zonal failover를 위해 다른 zone에 synchronous standby를 둔 HA (regional) instance를 배포하고, DR을 위해 cross-region read replica( asynchronous)를 추가합니다. 단일 zone outage에 대해 zero data loss(synchronous)를 충족하고, 다른 region에 near-real-time 데이터 사본을 제공하여 적절한 모니터링과 검증된 절차가 있으면 RPO/RTO 목표를 충족하도록 promote할 수 있으며, 애플리케이션 변경 없이도 가능합니다.

Cloud SQL은 cross-region replica에 대해 synchronous replication을 제공하지 않으며 cross-region replication은 asynchronous입니다. 또한 같은 region 내에서 zone 간에 asynchronous replica를 사용하는 것은 zonal outage에서 zero data loss를 보장하지 못하므로 요구사항을 위반합니다. 이 옵션은 올바른 패턴을 반대로 적용합니다: region 내에서는 synchronous(multi-zone HA), region 간에는 asynchronous(DR)가 필요합니다.

문제 분석

핵심 개념: 이 문제는 Cloud SQL for PostgreSQL의 high availability (HA)와 disaster recovery (DR)를 비교하는 내용을 테스트합니다. Cloud SQL에서 HA는 regional instance를 통해 달성되며, 동일한 region 내의 다른 zone에 synchronous standby (failover replica)를 유지합니다. region 간 DR은 일반적으로 asynchronous replication을 사용하는 cross-region read replica로 달성합니다. 정답인 이유: 단일 zone 장애를 데이터 손실 없이 허용해야 하며 RPO ≤ 5분을 충족해야 합니다. zonal failure에서 zero data loss를 달성하려면 다른 zone의 standby로 synchronous replication이 필요하며, 이는 Cloud SQL HA (regional)가 정확히 제공하는 방식입니다. regional outage에 대비하려면 다른 region에 데이터 사본이 있어야 하고 이를 빠르게 promote할 수 있어야 합니다. Cloud SQL의 cross-region replica는 asynchronous이지만, 일반적으로 replication lag가 낮으면 RPO를 수 분 단위로 충족할 수 있고, 운영 runbook/automation이 준비되어 있다면 promotion을 통해 수 분 내 복구 경로(RTO ≤ 5분)를 제공할 수 있습니다. 또한 이 토폴로지는 애플리케이션 변경을 피할 수 있는데, region 내 failover는 동일한 instance connection name을 유지하고, DR promotion은 애플리케이션 코드 변경 없이 connection endpoint/DNS 업데이트 또는 connection indirection layer를 통해 처리할 수 있기 때문입니다. 핵심 기능 / best practices: - Cloud SQL HA (regional) primary 사용: 다른 zone의 synchronous standby, zonal outage에 대한 automatic failover. - cross-region read replica(들) 추가: DR 및 선택적 read scaling을 위한 asynchronous replication. - replication lag 모니터링 및 alerting 설정으로 RPO 목표 충족 보장. - DR replica를 적절한 machine type/storage로 사전 프로비저닝하고 promotion 절차를 테스트하여 RTO 충족. - Google Cloud Architecture Framework에 정렬: reliability( multi-zone HA + multi-region DR), operational excellence(runbook, 테스트), cost awareness(cross-region replica는 비용 증가). 흔한 오해: - read replica가 region 간에 synchronous일 수 있다고 가정(Cloud SQL cross-region replication은 asynchronous). - 같은 region 내 replica만으로 regional outage를 커버한다고 믿음(그렇지 않음). - “모든 곳에서 asynchronous”여도 zonal failure에 대해 zero data loss를 보장할 수 있다고 생각(불가능). 시험 팁: - Cloud SQL에서: “HA/regional instance”는 zone 간 synchronous standby와 automatic failover를 의미. - “Read replicas”는 주로 scaling과 DR을 위한 것이며 asynchronous임. - 요구사항을 명시적으로 매핑: zonal outage에서 zero data loss => synchronous multi-zone; regional outage 복구 => cross-region replica + promotion + 운영 준비.

12
문제 12

You manage a development analytics environment running on Cloud SQL for MySQL in us-central1. The instance stores approximately 1.5 TB of data, with automated backups enabled to run daily and retain 7 copies. The workload is not mission-critical, and an RPO of 24 hours is acceptable. You need to lower monthly backup storage charges without disabling backups or changing the instance machine type. What should you change to reduce backup costs?

automated backups를 48 hours마다로 변경하면 생성되는 backups 수는 줄지만, 24-hour RPO 요구사항과 충돌합니다. 마지막 backup이 최대 48시간 전일 수 있다면 최대 2 days의 데이터를 잃을 수 있어 허용 가능한 data loss window를 초과합니다. 또한 Cloud SQL automated backups는 일반적으로 every-N-hours 방식의 cadence가 아니라 daily schedule window로 구성됩니다.

Cloud SQL은 automated backup storage에 대해 다른 storage tier(SSD vs HDD)를 선택하는 지원 옵션을 제공하지 않습니다. instance의 disk type은 primary storage의 성능/비용에 영향을 주지만, backup artifacts는 서비스가 관리하며 사용자가 선택할 수 있는 HDD/SSD tier 없이 backup storage로 과금됩니다. 따라서 이는 automated backups에 대한 유효하거나 적용 가능한 비용 절감 레버가 아닙니다.

Cloud SQL automated backups는 서비스가 관리하며, “같은 continent 내의 더 저렴한 region” 같은 임의의 위치에 저장되도록 구성할 수 없습니다. 일부 서비스는 multi-region 또는 cross-region storage classes를 지원하지만, Cloud SQL automated backups는 비용 최적화를 위해 이를 재배치하는 설정을 제공하지 않습니다. 또한 regions 간 backups 이동은 compliance 및 restore-time 고려사항을 유발할 수 있습니다.

retention을 7 days에서 2 days로 줄이면 retained되는 backup storage 양이 직접 감소하므로 월간 backup storage 요금이 줄어듭니다. daily backups는 계속 수행하되 과거 copies를 더 적게 유지하므로 24-hour RPO도 여전히 지원합니다. 이는 backup 구성을 비즈니스 요구사항에 정렬시키며, compute를 변경하거나 backups를 비활성화하지 않고 Cloud SQL backup 비용을 줄이는 가장 간단하고 지원되는 방법입니다.

문제 분석

핵심 개념: 이 문제는 Cloud SQL automated backup 비용을 유발하는 요인과, 명시된 복구 목표(RPO)를 더 낮은 비용으로 충족하도록 backup 구성을 조정하는 방법을 평가합니다. Cloud SQL for MySQL에서 automated backups는 backup artifacts를 생성하며, 이는 backup storage로 저장되고 과금됩니다. 지속적인 backup storage 사용량에 직접 영향을 주는 두 가지 주요 레버는 (1) 얼마나 많은 backups를 보관(retain)하는지와 (2) 각 backup의 크기(여기서는 변경하지 않음)입니다. 정답이 맞는 이유: 데이터가 1.5 TB이고 7-backup retention policy를 사용하면, 여러 일자에 걸친 retained backup storage에 대해 비용을 지불하게 됩니다. 요구사항에 따르면 워크로드는 mission-critical이 아니며 24시간 RPO가 허용됩니다. 24시간 RPO는 사고 발생 시점 기준으로 최대 24시간 이전 시점까지 복구할 수 있어야 함을 의미합니다. 2일치 backups(2 copies)를 보관하더라도 24-hour RPO를 지원하면서, 7 copies 대비 retained backup storage 양을 크게 줄일 수 있습니다. 따라서 automated backup retention을 7 days에서 2 days로 줄이는 것이 backups를 비활성화하거나 instance machine type을 변경하지 않고도 월간 backup storage 요금을 낮추는 가장 직접적이고, 지원되며, 예측 가능한 방법입니다. 주요 기능 / Best Practices: Cloud SQL에서는 automated backup retention(보관할 backups/일수)을 구성할 수 있습니다. Google Cloud Architecture Framework의 cost optimization 및 reliability 원칙에 따라 retention을 비즈니스 요구사항(RPO/RTO)에 맞추세요: 명시된 recovery objective에 필요 이상으로 보관하지 마세요. dev/test analytics 환경에서는 RPO가 완화되는 경우가 많아 더 짧은 retention이 일반적입니다. 흔한 오해: 많은 사람들이 backup frequency를 낮추는 것(Option A)이 최고의 비용 레버라고 가정합니다. 하지만 Cloud SQL automated backups는 daily scheduling을 중심으로 설계되어 있으며, 설령 frequency를 조정할 수 있다 하더라도 48시간마다로 줄이면 명시된 24-hour RPO를 위반합니다. 또 다른 사람들은 backup “storage tier”(Option B)를 바꾸거나 backups를 더 저렴한 region으로 옮길 수 있다고(Option C) 생각하지만, Cloud SQL automated backups는 backup artifacts에 대해 선택 가능한 HDD/SSD tier를 제공하지 않으며, automated backups를 임의의 더 저렴한 region에 저장하도록 지원되는 구성도 없습니다. Exam Tips: Cloud SQL에서 “backup costs를 줄여라”를 보면, 먼저 retention 설정을 확인하고 RPO를 여전히 충족하는지 검증하세요. RPO가 24 hours라면 최소 daily backups를 유지하고 운영 현실(backup 누락, 늦게 발견된 corruption)을 커버할 만큼의 copies를 보관하되, 비중요 환경에서 과도한 retention은 피하세요.

13
문제 13

You are designing a new centralized fleet maintenance scheduling system for 180 municipal depots, each with approximately 450 GB of historical data; you plan to onboard 12 depots per week over a 15-week phased rollout; the solution must use an SQL database, minimize costs and user disruption during each regional cutover, and allow capacity to scale up during weekday peaks and down on nights and public holidays to control spend; what should you do?

Bare Metal Solution의 Oracle RAC는 Oracle 워크로드에 대해 높은 성능과 호환성을 제공할 수 있지만, 일반적으로 비용이 높고 cloud-native managed database보다 운영 부담이 큽니다. 또한 비용 통제를 위해 용량을 자주 상/하향 스케일링해야 하는 요구사항을 자연스럽게 충족하지 못합니다. RAC 용량은 대체로 프로비저닝된 하드웨어에 고정됩니다. 이 옵션은 엄격한 호환성 요구가 있는 기존 Oracle RAC의 lift-and-shift에 더 적합합니다.

Sharded Cloud SQL 인스턴스는 인스턴스당 크기를 줄이고 depot를 격리할 수 있지만, 상당한 운영 복잡성(많은 인스턴스, 백업, 패치, connection routing, shard rebalancing)을 초래합니다. Cross-depot 분석과 중앙집중형 스케줄링 쿼리도 더 어려워집니다. Cloud SQL 스케일링은 주로 수직 확장(vertical)이며 중단을 유발할 수 있고, 스케일 다운은 제한적이며 평일/휴일 탄력성을 위해 빈번히 조정하도록 설계되지 않았습니다. 이는 중단 최소화 및 탄력적 비용 통제 요구사항과 충돌합니다.

Cloud Bigtable은 autoscaling과 대규모 처리량을 지원하지만, SQL relational database가 아니라 wide-column NoSQL database입니다. 요구사항에서 명시적으로 SQL database를 사용해야 한다고 했으므로 Bigtable은 제외됩니다. Bigtable은 다른 데이터 모델링(row keys, column families)이 필요하며, 추가 레이어 없이는 스케줄링 시스템에서 기대하는 relational joins/constraints를 제공하지 않습니다.

Cloud Spanner는 수평 확장성과 high availability를 갖춘 fully managed SQL database를 제공합니다. 온라인으로 compute(노드/processing units)를 스케일링할 수 있어, 평일 피크에는 용량을 늘리고 야간/휴일에는 줄여 비용을 관리할 수 있습니다. Spanner에는 built-in autoscaling이 없지만, Cloud Monitoring metrics와 자동화(Cloud Scheduler + Cloud Functions/Run)를 사용해 단계적 cutover 동안 최소한의 사용자 중단으로 용량을 조정하는 custom 메커니즘을 구현할 수 있습니다.

문제 분석

핵심 개념: 이 문제는 단계적 온보딩과 최소한의 전환(cutover) 중단으로 중앙집중형 멀티테넌트 워크로드를 지원할 수 있는 managed SQL database를 선택하는 능력을 평가합니다. 또한 예측 가능한 사용 패턴에 맞춰 용량을 상/하향 스케일링하여 비용을 통제하는 요구사항을 다룹니다. 더불어 SQL과 탄력적 스케일링을 지원하는 Google Cloud database가 무엇인지에 대한 지식도 확인합니다. 정답이 맞는 이유: Cloud Spanner는 보기 중 Google Cloud-native이며 fully managed relational (SQL) database로서, 수평 확장(horizontal scale)과 zone/region 전반의 high availability를 위해 설계된 유일한 선택지입니다. 180개 depot와 depot당 약 450 GB(총 약 81 TB) 규모에서는 단일 Cloud SQL 토폴로지가 운영 측면에서 복잡해지고(인스턴스 사이징, storage/IOPS, connection 관리, maintenance window 등) 현실적인 한계에 부딪힐 수 있습니다. Spanner는 downtime 없이 compute capacity(노드 또는 processing units 추가/제거)를 온라인으로 스케일링할 수 있어, 평일 피크에는 스케일 업하고 야간/휴일에는 스케일 다운하여 비용을 통제할 수 있습니다. 온보딩이 단계적(주당 12개 depot)이므로, depot-by-depot(또는 region-by-region)로 Spanner로 마이그레이션하면서 dual-write 또는 change data capture 패턴을 사용해 사용자 중단을 최소화한 통제된 cutover를 수행할 수 있습니다. 주요 기능 / best practices: - 강한 일관성(strong consistency)과 high availability를 제공하는 Spanner SQL(Regional 또는 multi-regional 구성). - 온라인 compute scaling: 노드/processing units 조정; scheduler(예: Cloud Scheduler + Cloud Functions/Run)와 metrics(Cloud Monitoring)를 결합해 “custom autoscaling” 구현. - 멀티테넌시를 위한 schema 설계: interleaving/secondary indexes를 신중히 사용; hotspot을 피하도록 primary key를 선택(예: depot_id + 시간 기반 구성요소에 필요 시 hashing 포함). - 마이그레이션 접근: staged backfill + CDC(Datastream 적용 가능 시, 또는 애플리케이션 레벨 dual writes)로 각 cutover 동안 downtime 감소. 흔한 오해: Cloud SQL은 더 저렴하고 단순해 보이지만, 180개 depot를 여러 인스턴스로 sharding하면 운영 오버헤드가 증가하고, cross-depot 리포팅이 복잡해지며, 중단을 유발하는 인스턴스 리사이징 없이 진정한 scale-down/scale-up 탄력성을 제공하지 못합니다. Bigtable autoscaling은 매력적이지만 SQL relational database가 아닙니다. Bare Metal의 Oracle RAC는 강력하지만 비용이 높고 managed, elastic scaling 목표와 정렬되지 않습니다. Exam tips: 요구사항에 (1) SQL, (2) 매우 큰 총 데이터셋, (3) 수평 확장성과 high availability 필요, (4) 온라인 용량 변경이 포함되면 Spanner가 기본 정답입니다. 또한 Spanner에는 built-in autoscaling이 없으므로, 시험 문제에서는 Cloud Monitoring과 자동화를 사용한 scheduled/metric-driven scaling 구현을 기대하는 경우가 많습니다.

14
문제 14

Your company needs to relocate a high-traffic payment ledger database from a co-location data center to Google Cloud. The source is MySQL 8.0.28 using the InnoDB engine with binary logging enabled in ROW format; the dataset is 1.6 TB, averaging 900 TPS with bursts up to 1,500 TPS. A dedicated Cloud VPN tunnel provides 1 Gbps bandwidth between on-premises and Google Cloud. You must preserve ACID transactions and keep the production cutover under 3 minutes at 02:00 UTC. Cloud SQL for MySQL supports the source version. What should you do?

정답입니다. Database Migration Service는 지원되는 MySQL 데이터베이스를 최소한의 다운타임으로 Cloud SQL로 마이그레이션하기 위해 Google이 권장하는 서비스입니다. 이 서비스는 1.6 TB 데이터셋의 초기 전체 load를 수행한 다음, MySQL binlog-based replication을 사용하여 source의 지속적인 변경 사항을 계속 반영합니다. 이는 900 TPS를 유지하고 최대 1,500 TPS까지 증가하는 데이터베이스에 정확히 필요한 방식입니다. source에 이미 ROW format의 binary logging이 활성화되어 있으므로, 사전 요구 사항도 DMS continuous migration과 잘 맞습니다. 이를 통해 팀은 대량 전송 중에도 production을 계속 온라인 상태로 유지할 수 있고, 3분의 cutover 시간 창은 writes 중지, replication 따라잡기, 마이그레이션 완료, 클라이언트 리디렉션에만 사용할 수 있습니다.

오답입니다. Cloud Data Fusion은 주로 ETL 및 데이터 통합 플랫폼이지, 낮은 다운타임 cutover를 위한 전용 트랜잭션 데이터베이스 마이그레이션 서비스가 아닙니다. 테이블별 pipeline 접근 방식은 높은 트래픽의 payment ledger에 대해 commit 순서, 트랜잭션 일관성, 또는 continuous synchronization을 자연스럽게 보장하지 못합니다. 또한 마이그레이션 중 발생하는 변경 사항을 처리하려면 상당한 다운타임이나 사용자 정의 reconciliation logic이 필요합니다. 따라서 엄격한 3분 미만 cutover 요구 사항이 있는 1.6 TB OLTP 데이터베이스에는 적합하지 않습니다.

오답입니다. mysqldump는 logical export 도구이며, 다운타임을 3분 미만으로 유지해야 하는 1.6 TB production 데이터베이스에는 일반적으로 너무 느립니다. export를 압축하더라도 dump, 전송, import, 검증에 걸리는 총 시간은 허용된 outage 시간 창보다 훨씬 길어집니다. 이 방법은 export와 import 중 source와 target 모두에 큰 부하를 주어 운영 위험도 증가시킵니다. 더 작은 데이터베이스나 긴 다운타임이 허용되는 maintenance window에는 적절할 수 있지만, 이 시나리오에는 맞지 않습니다.

오답입니다. 테이블을 CSV로 export하고 Cloud SQL로 import하는 방식은 이 정도 규모와 중요도를 가진 트랜잭션 MySQL 마이그레이션에는 적합하지 않은 수동 bulk-load 패턴입니다. CSV 워크플로는 상당한 추가 작업 없이는 triggers, routines, foreign keys 및 기타 schema-level objects와 같은 전체 데이터베이스 의미를 보존하지 못합니다. import 후 indexes와 constraints를 재구성하면 시간과 복잡성이 더 늘어나므로 outage는 3분을 훨씬 초과하게 됩니다. 이 접근 방식은 낮은 다운타임 마이그레이션이 필요한 payment ledger보다는 분석용 데이터 이동에 더 적합합니다.

문제 분석

핵심 개념: 이 문제는 continuous replication(binlog-based CDC)을 사용하는 Database Migration Service (DMS)를 통해 MySQL을 Cloud SQL로 낮은 다운타임으로 마이그레이션하는 방법을 테스트합니다. 데이터베이스 계층에서 ACID 동작을 유지하면서 엄격한 cutover RTO(3분 미만)를 충족하는 데 중점을 둡니다. 정답인 이유: 1.6 TB 데이터셋과 지속적인 900 TPS(최대 1,500까지 급증) 환경에서는 어떤 “offline” export/import 방식(mysqldump/CSV)도 3분보다 훨씬 오래 걸리며 긴 다운타임을 초래합니다. DMS는 MySQL 8.0에서 Cloud SQL for MySQL로의 마이그레이션을 지원하며, 초기 load 이후 MySQL binary logs의 ROW format 기반 continuous replication을 수행할 수 있습니다. 초기 load를 미리 실행하고 replication이 거의 따라잡은 상태를 유지하면, 최종 cutover는 짧고 통제된 작업이 됩니다: source에서 writes를 중지하고, replication lag가 거의 0이 되도록 기다린 뒤, destination을 promote하고, 애플리케이션의 연결 대상을 전환합니다. 주요 기능 / 구성 / 모범 사례: - binlog-based replication을 사용하는 DMS continuous migration을 사용합니다(GTID를 사용할 수 있으면 권장, 그렇지 않으면 file/position). source에 ROW binlog format(문제에서 제공됨)이 설정되어 있고, 초기 load 중 logs가 삭제되지 않도록 적절한 retention이 설정되어 있는지 확인합니다. - 네트워크 처리량을 검증합니다: 1 Gbps VPN(이론상 약 125 MB/s, 실제는 더 낮음)은 continuous replication과 시간에 걸친 초기 load에 충분합니다. 핵심은 cutover가 1.6 TB를 해당 시간 창 동안 전송하는 것이 아니라, 남아 있는 변경 사항을 반영하는 데만 의존한다는 점입니다. - 트랜잭션 무결성을 유지합니다: InnoDB + row-based binlogs는 commit된 변경 사항을 결정적으로 replication할 수 있게 합니다. 애플리케이션 cutover에는 connection string 업데이트와 필요 시 DNS/connection pool 새로고침이 포함되어야 합니다. - Google Cloud Architecture Framework의 reliability 지침을 따릅니다: 리허설을 수행하고, replication lag를 모니터링하며, rollback 계획을 수립합니다(source를 잠시 read-only 상태로 유지하되 사용 가능하게 둠). 흔한 오해: - “mysqldump가 가장 간단하다”: 작은 데이터베이스에는 맞지만, 1.6 TB에서는 긴 다운타임이 발생하고 3분 요구 사항을 충족하지 못할 위험이 큽니다. - “ETL 도구로 데이터를 마이그레이션할 수 있다”: Data Fusion pipelines는 변환/분석 중심의 데이터 이동용이지, 거의 무중단으로 트랜잭션 일관성을 유지하기 위한 용도가 아닙니다. - “CSV export가 더 빠르다”: schema 충실도(constraints, triggers, routines)를 잃고, index 재구성이 필요하며, 여전히 긴 다운타임을 의미합니다. 시험 팁: 대용량 데이터셋 + 엄격한 cutover 시간 창 + binlogs가 활성화된 MySQL이 보이면, 기본적으로 DMS continuous migration(CDC)을 떠올리세요. dump/CSV import는 작은 데이터셋이거나 다운타임이 허용될 때만 사용하세요. 또한 Cloud SQL은 read replicas를 지원하지만, 환경 간 마이그레이션은 managed되고 모니터링 가능한 cutover를 위해 DMS로 처리하는 것이 가장 적합하다는 점도 기억하세요.

15
문제 15

During a quarterly disaster-recovery review at a fintech company, you discover that a production Cloud SQL for MySQL 8.0 instance (single-zone, us-central1-a, 800 GB with storage auto-increase enabled) is not configured for high availability (HA), while SLOs require RTO < 60 seconds and zero data loss during zonal failures; you have a 30-minute maintenance window this weekend and cannot accept multi-hour downtime for data migration. Following Google-recommended practices, how should you enable HA on this existing instance with the least operational risk?

새 HA 인스턴스를 만들고 export/import를 사용하는 것은 전형적인 마이그레이션 패턴이지만, 여기서는 위험이 큽니다. 800 GB에 대한 export/import는 수 시간이 걸릴 수 있고 cutover window가 필요합니다. 또한 쓰기를 동결하거나 추가 replication을 구현하지 않으면 데이터 손실 위험이 있습니다. 수 시간 다운타임을 허용하지 않는 제약을 위반하며, in-place HA 활성화에 비해 운영 위험이 가장 낮은 방법도 아닙니다.

Cloud Data Fusion은 ETL/통합 도구이며, HA를 위해 프로덕션 MySQL 데이터베이스를 마이그레이션하는 표준 또는 최저 위험 방법이 아닙니다. 이를 전체 데이터베이스 마이그레이션에 사용하면 복잡성, 운영 오버헤드, 데이터 일관성 이슈 가능성이 증가합니다. 또한 추가 replication과 세심한 오케스트레이션 없이는 cutover/RPO 문제를 본질적으로 해결하지 못하므로, 엄격한 다운타임 제약 하에서는 부적절합니다.

기존 인스턴스를 patch하여 availability-type=REGIONAL로 설정하는 것은 최소한의 운영 위험으로 HA를 활성화하기 위한 Cloud SQL의 의도된 접근 방식입니다. 전체 데이터 마이그레이션을 피하고, 다른 존에 standby를 생성하는 Cloud SQL의 관리형 기능(동기식 복제 및 자동 failover)을 활용합니다. 일반적으로 짧은 maintenance 중단만 필요하므로 30분 window와 HA SLO에 부합합니다.

인스턴스를 수동으로 종료하고 HA를 “toggle”하는 것은 권장되거나 필요한 절차가 아닙니다. HA 활성화는 인스턴스 update(console/API/gcloud patch)를 통해 수행되며, 수동 stop/start 단계를 도입하면 오류와 다운타임 연장 가능성이 커집니다. 또한 옵션 C가 제공하는 통제되고 지원되는 방식 대비 추가적인 가치가 없습니다.

문제 분석

핵심 개념: 이 문제는 MySQL용 Cloud SQL 고가용성(HA)과, 최소한의 위험과 다운타임으로 기존 인스턴스에 HA를 사후 적용(retrofit)하는 방법을 평가합니다. Cloud SQL에서 HA는 REGIONAL(availability-type=REGIONAL) 구성으로 제공되며, 동일 리전 내 다른 존에 standby를 생성하고 동기식 복제와 자동 failover를 사용합니다. 정답인 이유: 옵션 C는 Google이 권장하는 운영 접근 방식입니다. 기존 인스턴스를 REGIONAL로 patch하는 것입니다. Cloud SQL은 availability type을 업데이트하여 기존 인스턴스에서 HA를 활성화하는 것을 지원합니다. 이는 전체 논리적 마이그레이션(export/import)을 피하고, cutover 위험이 있는 병렬 스택 구축도 피합니다. 짧은 maintenance window 제약과 수 시간 다운타임을 피해야 한다는 요구사항에 부합합니다. 이 작업은 재구성 중 일부 다운타임(일반적으로 수 분, 인스턴스 크기와 워크로드에 따라 달라짐)이 발생하지만, 데이터 마이그레이션과 비교하면 가장 위험이 낮은 경로입니다. 주요 기능 및 모범 사례: REGIONAL HA는 primary와 standby를 서로 다른 존에 배치하여(존 장애 보호) 동기식 복제를 사용해 데이터 손실을 최소화합니다(존 장애에 대해 “zero data loss” 기대치를 충족). 또한 낮은 RTO로 자동 failover를 활성화합니다(대개 60초 훨씬 이내이지만, 애플리케이션은 Cloud SQL connector/proxy 및 재시도 로직 같은 권장 연결 방식을 사용해야 함). Storage auto-increase도 계속 지원되며, 추가 standby 리소스를 위한 충분한 regional quota를 확보해야 합니다. maintenance window에 변경을 계획하고, 통제된 failover 테스트로 검증하세요. 흔한 오해: Export/import(A) 또는 Data Fusion(B)도 HA를 달성할 수는 있지만, 800 GB에 대해 마이그레이션 시간이 길고 cutover 복잡도가 높으며, replication을 추가하고 cutover를 정교하게 오케스트레이션하지 않으면 “zero data loss” 요구사항을 놓칠 위험이 큽니다. 옵션 D는 HA를 “toggle”하라고 하지만 수동 stop/start를 암시합니다. Cloud SQL HA 활성화는 임의의 shutdown 절차가 아니라 update/patch 작업으로 수행되며, 수동 단계는 운영 위험을 증가시킵니다. 시험 팁: Cloud SQL에서 “HA”는 일반적으로 availability-type=REGIONAL(다른 존의 standby, 자동 failover)에 해당합니다. 기존 인스턴스에서 운영 위험이 가장 낮은 방법을 묻는다면, 마이그레이션보다 서비스가 지원하는 in-place 구성 변경을 우선하세요. HA 요구사항은 항상 RTO/RPO와 연결해 생각하세요. REGIONAL HA는 존 장애에 대해 낮은 RTO와 거의 0에 가까운 RPO를 목표로 하지만, 여전히 클라이언트 측 재시도/연결 모범 사례가 필요합니다.

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

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

16
문제 16

Your team runs a meal-delivery ordering platform in us-central1. The API is served from Cloud Run, and transactional data is stored in a single Cloud SQL for PostgreSQL instance with automatic maintenance updates enabled. 92% of customers are in the America/Chicago time zone and expect the app to be available every day from 6:00 to 22:00 local time. Security policy requires that database maintenance patches be applied within 7 days of release. You need to apply regular Cloud SQL maintenance without creating downtime for users during operating hours. What should you do?

유지보수 window를 설정하면 유지보수 발생 시점을 제어하는 데는 도움이 되지만, 패치에 재시작이 필요한 경우가 많기 때문에 단일 Cloud SQL 인스턴스에서 다운타임을 방지하지는 못합니다. 또한 Cloud SQL 유지보수 window는 UTC로 구성되므로 “02:00–03:00 America/Chicago”처럼 로컬 타임존으로 설정이 적용되는 방식이 아닙니다. 비프로덕션을 먼저 적용하도록 sequencing하는 것은 좋은 관행이지만, 프로덕션 가용성 문제를 해결하지는 못합니다.

read replica는 읽기 트래픽을 오프로딩할 수 있지만, primary 유지보수 동안 트랜잭션(쓰기 중심) 시스템에 대해 자동적이고 끊김 없는 연속성을 제공하지는 못합니다. Cloud SQL replica는 비동기이며, replica를 primary로 promotion하는 것은 중단을 수반하는 운영 이벤트이고 일반적으로 연결 endpoint 변경과 신중한 failover 계획이 필요합니다. 이는 운영 시간 동안 사용자 다운타임을 피해야 한다는 요구사항을 충족하지 못합니다.

유지보수 알림과 일정 재조정은 운영 측면에서 유용하지만 다운타임을 제거하지는 못합니다. 요구사항은 7일 이내 패치를 적용하고 06:00–22:00 로컬 시간 동안 다운타임을 피하는 것입니다. 사용자에게 알린다는 것은 다운타임을 수용한다는 의미이므로 명시된 목표와 충돌합니다. 또한 유지보수 시점은 Google의 유지보수 정책과 패치 컴플라이언스 기간에 의해 제약될 수 있습니다.

Cloud SQL High Availability (regional)는 계획된 유지보수와 비계획 장애 모두에서 다운타임을 최소화하도록 설계되었습니다. 다른 zone에 동기식 standby가 있으므로, 유지보수 중 Cloud SQL이 fail over하여 서비스가 최소한의 중단으로 계속 사용 가능하도록 할 수 있습니다. 이는 Architecture Framework의 신뢰성 원칙에 가장 잘 부합하며, 운영 시간 동안 사용자에게 영향을 주지 않으면서 7일 이내 패치 요구사항을 충족합니다.

문제 분석

핵심 개념: 이 문제는 Cloud SQL 유지보수 동작과 계획된 유지보수 동안 가용성을 확보하도록 설계하는 방법을 평가합니다. Cloud SQL에서 유지보수(OS/데이터베이스 패치)는 재시작이 필요할 수 있으며, 따라서 단일 인스턴스 배포에서는 다운타임이 발생할 수 있습니다. Google Cloud Architecture Framework의 핵심 아키텍처 원칙은 고가용성을 위해 설계하고 단일 장애 지점을 최소화하는 것입니다. 정답이 맞는 이유: Cloud SQL for PostgreSQL에 High Availability (regional)를 활성화하면 동일 리전(us-central1) 내의 다른 zone에 동기식(synchronous) standby를 둔 primary 인스턴스가 생성됩니다. 유지보수 중 Cloud SQL은 standby로 제어된 failover를 수행하고 업데이트를 적용한 뒤 (선택적으로) 다시 fail back할 수 있습니다. 이는 단일 인스턴스를 패치하는 것에 비해 사용자에게 보이는 중단을 크게 줄여, 패치를 7일 이내 적용해야 하는 정책을 준수하면서도 운영 시간(06:00–22:00 America/Chicago) 동안 다운타임이 없어야 한다는 요구사항을 충족하는 데 도움이 됩니다. 주요 기능 / 구성: - Cloud SQL HA (regional)는 자동 failover 및 regional IP 옵션을 포함한 zonal redundancy를 사용합니다. - 유지보수는 스케줄링할 수 있지만, 유지보수 window가 있더라도 단일 인스턴스는 재시작 동안 여전히 다운타임을 겪습니다. - HA는 고가용성과 계획/비계획 다운타임 감소가 필요한 프로덕션 워크로드에 권장되는 접근 방식입니다. - Cloud Run은 stateless이며 짧은 연결 끊김을 허용할 수 있고, HA는 데이터베이스 측 중단 구간을 최소화합니다. 흔한 오해: - 유지보수 window만 설정(Option A)하면 다운타임이 제거되는 것이 아니라 발생 시점만 제어합니다. 또한 Cloud SQL 유지보수 window는 UTC로 구성되며, 프로덕션이 단일 인스턴스라면 인스턴스 간 “sequencing”은 도움이 되지 않습니다. - read replica(Option B)는 읽기 확장과 재해 복구 패턴에 유용하지만 비동기(asynchronous)이며, 유지보수 중 쓰기(write)에 대해 자동으로 primary를 대체하려면 promotion과 애플리케이션 재구성이 필요합니다. - 사용자에게 알림(Option C)은 운영 시간 동안 다운타임을 피해야 한다는 요구사항을 충족하지 못합니다. 시험 팁: Cloud SQL에서 “유지보수 중 다운타임 회피”가 보이면 먼저 HA (regional)를 떠올리세요. 유지보수 window는 스케줄링을 위한 것이지 다운타임을 제거하는 것이 아닙니다. read replica는 끊김 없는 쓰기 가용성을 제공하지 않습니다. 또한 Cloud SQL 유지보수 window는 UTC로 지정되며, 보안 패치 타임라인 때문에 제한된 기간 내 유지보수가 강제될 수 있으므로 HA가 가장 안전하고 컴플라이언스 친화적인 설계입니다.

17
문제 17

You are deploying a new Java service on a Windows Server 2019 VM in your company’s on-premises data center (no Cloud VPN or Interconnect to Google Cloud), and the service uses JDBC on port 5432 to connect to a Cloud SQL for PostgreSQL instance that has a private IP 10.20.30.40 and a public IP 34.98.120.10, with SSL disabled on the instance; you must ensure the service can access the database without making any configuration changes to the Cloud SQL instance—what should you do?

오답입니다. PostgreSQL에 대한 JDBC 인증은 Google Workspace 사용자 이름/비밀번호가 아니라( PostgreSQL/Cloud SQL에 생성된) 데이터베이스 사용자를 사용합니다. public IP가 도달 가능하더라도 Workspace 자격 증명은 유효한 데이터베이스 자격 증명이 아닙니다. 또한 Cloud SQL Auth Proxy 없이 public IP로 직접 연결하려면 일반적으로 authorized networks 구성 또는 기타 인스턴스 측 제어가 필요하며, 문제에서 인스턴스 변경을 금지하고 있습니다.

오답입니다. private IP(10.20.30.40)는 연결된 VPC 네트워크 내부 또는 Cloud VPN/Interconnect를 통해 온프레미스에서만 도달 가능합니다. 시나리오는 VPN 또는 Interconnect가 없다고 명시하므로 온프레미스 VM에서 private IP로 가는 라우트가 없습니다. 올바른 데이터베이스 자격 증명이 있어도 private 주소로의 직접 JDBC 연결은 실패합니다.

오답입니다. service account와 함께 Cloud SQL Auth Proxy를 사용하는 것은 모범 사례이지만, 인스턴스의 private IP로 연결하도록 구성하려면 해당 private IP에 대한 네트워크 연결성이 여전히 필요합니다. VPN/Interconnect가 없거나(또는 동일 VPC가 아니면) 온프레미스 VM은 10.20.30.40에 도달할 수 없습니다. proxy가 private IP 라우팅을 마법처럼 제공하는 것이 아니라, Cloud SQL 엔드포인트로의 인증된 터널링을 제공합니다.

정답입니다. VM이 on-premises에 있고 Cloud VPN 또는 Interconnect가 없으므로, data center에서 인스턴스의 private IP 10.20.30.40에 도달할 수 없습니다. Cloud SQL Auth Proxy는 Windows Server에서 실행할 수 있으며 service account로 인증할 수 있고, 인스턴스의 public 경로를 사용하여 Google-managed connectivity를 통해 Cloud SQL 인스턴스에 대한 secure connection을 설정합니다. 그런 다음 Java application은 JDBC를 사용하여 proxy의 local listener에 연결해야 하며, proxy가 인스턴스 구성 변경 없이 Cloud SQL에 대한 authenticated, encrypted connection을 처리합니다.

문제 분석

핵심 개념: 이 문제는 외부(온프레미스) 환경에서의 Cloud SQL 연결 패턴, 특히 private IP 접근과 public IP 접근의 차이 및 Cloud SQL Auth Proxy(또는 Cloud SQL connectors)를 언제 사용해야 하는지를 테스트합니다. 또한 IAM과 데이터베이스 인증의 차이, 그리고 보안 연결 모범 사례도 간접적으로 평가합니다. 정답이 맞는 이유: VM이 Cloud VPN 또는 Cloud Interconnect 없이 온프레미스 데이터 센터에 있으므로 Cloud SQL 인스턴스의 private IP(10.20.30.40)로 가는 네트워크 경로가 없습니다. Cloud SQL의 private IP는 VPC에 연결된 네트워크(동일 VPC, peered VPC, 또는 VPN/Interconnect를 통한 온프레미스)에서만 도달 가능합니다. 또한 Cloud SQL 인스턴스 구성을 변경할 수 없으므로(VPN/Interconnect 추가, authorized networks 변경, SSL 강제 등 불가) 가능한 유일한 연결 경로는 인스턴스의 public IP(34.98.120.10)입니다. 인스턴스 설정을 변경하지 않고도 안전하게 연결하려면 service account와 함께 Cloud SQL Auth Proxy를 사용해야 합니다. proxy는 IAM을 사용해 인증되고 암호화된 터널을 Cloud SQL로 설정하며, 애플리케이션은 표준 JDBC로 로컬(예: 127.0.0.1:5432)에 연결합니다. 주요 기능 / 모범 사례: - Cloud SQL Auth Proxy(또는 language connectors)는 인스턴스의 “require SSL” 설정이 비활성화되어 있어도 전송 중 IAM 기반 권한 부여와 TLS 암호화를 제공합니다. - 클라이언트에서 Google 관리 엔드포인트로 나가는 outbound 연결로 동작하며, 일반적으로 클라이언트 측에서 inbound 방화벽 오픈이 필요하지 않습니다. - 최소 권한의 service account(예: roles/cloudsql.client)를 사용하고, 광범위한 네트워크 컨텍스트에서 데이터베이스 자격 증명을 노출하는 것을 피합니다. - Google Cloud Architecture Framework 보안 원칙(강력한 identity, 안전한 연결, 공격 표면 최소화)에 부합합니다. 흔한 오해: - Google Workspace 자격 증명과 데이터베이스 자격 증명을 혼동(Cloud SQL은 PostgreSQL 인증에 데이터베이스 사용자를 사용하며, Workspace 로그인은 JDBC 인증 메커니즘이 아님). - “IP를 알면” private IP가 어디서나 도달 가능하다고 가정. hybrid connectivity가 없으면 라우팅되지 않습니다. - SSL이 비활성화되어 있으면 트래픽이 암호화되지 않는다고 생각. proxy는 여전히 Cloud SQL로 TLS를 사용합니다. 시험 팁: “VPN/Interconnect 없는 온프레미스”를 보면 private IP에 의존하는 선택지는 제거하세요. “인스턴스 변경 불가”를 보면 인스턴스 측 네트워크 allowlisting이나 SSL 강제 변경보다 Cloud SQL Auth Proxy/Connectors를 우선하세요. 또한 기억할 점: IAM은 누가 연결할 수 있는지(proxy/connector)를 제어하고, PostgreSQL users/passwords는 연결 후 데이터베이스 로그인을 제어합니다.

18
문제 18

You manage a small, non-critical Cloud SQL for PostgreSQL instance (2 vCPUs, 50-GB storage) used by a staging QA pipeline; the business accepts a recovery point objective of up to 72 hours and you want to minimize ongoing operational and storage costs while still retaining basic recovery capability—what backup/restore configuration should you choose?

모든 백업을 비활성화하고 transaction log retention도 끄는 것은 절대적인 최저 비용이지만, 복구 기능을 제거합니다. 비중요 시스템이라도 문제에서 “기본 복구 기능을 여전히 유지”해야 한다고 명시합니다. Backups나 PITR logs가 없으면, 실수로 인한 삭제, 손상, 또는 인스턴스 장애 이후(고가용성이 커버하는 범위를 넘어) 복구할 수 없습니다. 이는 명시된 비즈니스 요구사항을 충족하지 못합니다.

Transaction log retention을 끈 상태에서 하루 1회 manual backup은 72시간 RPO를 충족할 수 있습니다(일일 백업은 요구사항보다 더 자주 수행). 그러나 운영 오버헤드와 위험이 증가합니다. 누군가가 백업이 생성되고 보존되며 실수로 삭제되지 않도록 보장해야 합니다. 또한 manual backups는 라이프사이클을 직접 관리하지 않으면 retention을 본질적으로 최적화하지 못합니다. “지속적인 운영 비용 최소화” 관점에서는 automated backups가 선호됩니다.

Transaction log retention을 끈 상태의 automated backups는 PITR보다 낮은 비용으로 관리형, 저운영( low-ops )의 기본 복구 방법을 제공합니다. Backup retention을 최소 3일로 설정하여 72시간 RPO를 충족할 수 있습니다. 이 구성은 WAL/transaction logs를 보존하는 추가 스토리지 비용을 피하면서도 가장 최근 automated backup으로의 복구를 가능하게 합니다. “기본 복구 기능”과 비용 최소화에 가장 잘 부합합니다.

Transaction log retention을 켠 automated backups는 PITR을 활성화하여 백업 사이의 특정 timestamp로 복구할 수 있습니다. 이는 더 엄격한 RPO/RTO 목표와 빠르게 발견되는 논리적 오류로부터의 보호에 유용합니다. 하지만 지속적인 스토리지 사용량(transaction logs)이 증가하고 비용이 상승할 수 있으며, 비즈니스가 최대 72시간의 데이터 손실을 허용하는 경우 의미 있는 이점을 제공하지 못합니다. Staging QA에는 과도한 설계입니다.

문제 분석

핵심 개념: 이 문제는 Cloud SQL for PostgreSQL 백업 전략의 트레이드오프(automated backups vs manual backups, 그리고 transaction log retention(시점 복구/point-in-time recovery/PITR))를 평가합니다. 또한 Google Cloud Architecture Framework의 cost optimization 및 operational excellence 원칙에 맞춰, 가장 낮은 운영 및 스토리지 비용으로 RPO 요구사항을 충족하는 데 초점을 둡니다. 정답이 맞는 이유: RPO가 최대 72시간이라는 것은 비즈니스가 최대 3일치 데이터 손실을 허용할 수 있음을 의미합니다. 기본적인 복구 기능을 제공하면서도 가장 저비용인 구성은 automated backups를 활성화하되 transaction log retention(PITR)은 비활성화하는 것입니다. Automated backups는 예약된 관리형 백업을 제공하며 보존(retention) 제어와 최소한의 운영자 개입으로 동작합니다. PITR을 끄면 WAL/transaction logs를 유지하는 데 필요한 추가 스토리지 및 지속적인 쓰기/보존 오버헤드를 피할 수 있는데, 완화된 RPO에서는 이것이 불필요합니다. 주요 기능 및 모범 사례: Cloud SQL automated backups는 서비스에서 관리되며 retention window(백업/일수)를 설정할 수 있습니다. 72시간 RPO를 만족하려면 retention이 최소 3일을 커버하도록 보장해야 합니다(일반적으로 3–7일로 설정). Transaction log retention을 비활성화하면 백업 사이의 임의 시점으로 복구하는 기능은 사라지지만, 스토리지 사용량과 비용이 줄어듭니다. 중요도가 낮은 staging QA 파이프라인에서는 보통 최신 백업으로의 복구(restore-to-last-backup)로 충분합니다. 흔한 오해: 옵션 B(manual daily backups)는 빈도를 직접 제어하므로 더 저렴해 보일 수 있지만, 운영 부담이 증가하고 백업 누락 위험이 있으며 manual backups도 스토리지를 사용합니다. 옵션 D(automated + PITR)는 가장 강력하지만, 완화된 RPO에 비해 비용과 복잡도가 증가하여 정당화되기 어렵습니다. 옵션 A(no backups)는 비용을 최소화하지만 기본 복구 기능을 유지해야 한다는 요구사항을 위반합니다. 시험 팁: RPO를 백업 빈도/보존으로 변환하세요: RPO가 72시간이면 최소 72시간마다 백업이 있어야 하고 그 기간만큼 보존되어야 합니다. 운영 부담이 적어야 하는 환경에서는 automated backups를 사용하세요. PITR은 더 세밀한 복구(분/시간 단위)나 백업 사이에 발생한 논리적 손상에 대한 보호가 필요할 때만 활성화하세요. 비용 관련 문제에서는 PITR이 지속적인 transaction log 스토리지를 의미하며, 일반적으로 백업만 사용하는 것보다 비용이 더 높다는 점을 기억하세요.

19
문제 19

You operate a Cloud SQL for PostgreSQL deployment in Google Cloud. The primary instance runs in zone europe-west1-b, and a read replica runs in zone europe-west1-c within the same region. An alert reports that the read replica in europe-west1-c was unreachable for 11 minutes due to a zonal network disruption. You must ensure that the read-only workload continues to function and that the replica remains available with minimal manual intervention. What should you do?

primary의 clone은 read replica와 동일하지 않습니다. clone은 독립적인 복사본이며, 생성 후 primary로부터 asynchronous replication을 계속하지 않습니다. read traffic에 clone을 사용하면 시간이 지나면서 data divergence가 발생하고 더 많은 수동 관리가 필요합니다. 따라서 관리되는 read replica topology를 적절히 복구하지 못합니다.

이것이 최선의 선택인 이유는 read-only workload가 serving replica에 의존하고 있는데, 유일한 replica에 장시간 접근할 수 없기 때문입니다. 새 read replica를 생성하는 것은 primary를 write용으로 online 상태로 유지하면서 read capacity를 복구하는 가장 직접적인 방법입니다. traffic을 새 replica로 리디렉션하면 workload 요구 사항을 충족할 수 있으며, automatic recovery를 기다리는 것은 서비스 연속성을 보장하지 못합니다. 여러 replica를 미리 구성해 두는 것에 비하면 이상적이지는 않지만, 제시된 선택지 중에서는 가장 강력한 복구 조치입니다.

이 선택지는 read replica가 정상 zone에서 자동으로 다시 생성된다는 가정에 의존하기 때문에 올바르지 않습니다. Cloud SQL은 zonal disruption 이후 read 가용성을 유지하기 위해 단일 read replica를 다른 곳에 자동으로 재생성한다는 문서화된 보장을 제공하지 않습니다. 상태를 확인하는 것은 합리적인 운영 점검이지만, 그 자체로 read-only workload가 계속 동작하도록 보장하지는 않습니다. 문제는 단순히 무엇을 관찰해야 하는지가 아니라, 가용성을 보장하기 위해 무엇을 해야 하는지를 묻고 있습니다.

primary를 재시작하는 것은 불필요하며 잠재적으로 해롭습니다. 문제는 primary database process가 아니라 zonal network disruption으로 인해 replica에 접근할 수 없다는 점입니다. primary를 재시작하면 write traffic이 중단될 수 있고 replica 또는 read service의 복구도 보장하지 못합니다. 실제 failure domain을 해결하지 못한 채 위험만 추가합니다.

문제 분석

핵심 개념: 이 문제는 zonal disruption 동안 Cloud SQL for PostgreSQL read replica의 가용성과 운영 복구를 테스트합니다. Cloud SQL read replica는 별도의 asynchronous replica instance이며, 한 zone에 있는 단일 replica는 여전히 해당 zone의 read traffic에 대한 single point of failure입니다. Cloud SQL은 단일 read replica에 대해 automatic read workload failover를 제공하지 않으므로, 지속적인 read 가용성이 필요하다면 replica capacity를 직접 복구하거나 미리 여러 replica로 설계해야 합니다. 정답인 이유: 유일한 read replica에 11분 동안 접근할 수 없었고, 요구 사항이 최소한의 수동 개입으로 read-only workload가 계속 동작하도록 보장하는 것이므로, 가장 적절한 조치는 최신 사용 가능한 상태에서 새 read replica를 생성하고 read traffic을 그쪽으로 리디렉션하는 것입니다. 이렇게 하면 primary를 중단하지 않고 serving replica를 복구할 수 있습니다. 이는 zonal failure 이후 read 가용성을 다시 확립하기 위한 선택지 중 가장 적절한 운영 대응입니다. 주요 특징: - Cloud SQL read replica는 asynchronous이며, 그 자체만으로 automatic read failover semantics를 제공하지 않습니다. - replica zone에 영향을 주는 zonal outage가 발생하면, 다른 replica가 이미 존재하지 않는 한 read traffic은 serving target을 잃을 수 있습니다. - read replica를 다시 만드는 것은 관리적 복구 작업입니다. 더 강한 복원력을 위해서는 여러 zone에 걸쳐 multiple replica를 배포하고 application 측 routing 또는 connection management를 사용해야 합니다. 흔한 오해: 흔한 실수는 zonal disruption 이후 Cloud SQL이 자동으로 다른 zone에 read replica를 다시 생성한다고 가정하는 것입니다. 또 다른 오해는 primary를 재시작하면 replica 복구에 도움이 된다는 생각인데, 일반적으로는 불필요한 write 중단만 추가합니다. clone 역시 read replica의 대체물이 아닙니다. clone은 replication target이 아니라 독립적인 복사본이기 때문입니다. 시험 팁: - primary HA/failover 동작과 read replica 동작을 구분하세요. 둘은 동일하지 않습니다. - 문제가 read workload 연속성 유지에 대해 묻는다면, replica redundancy와 traffic redirection을 떠올리세요. - replica가 하나뿐이고 그것이 사용할 수 없게 되면, 아키텍처에 이미 추가 replica가 포함되어 있지 않은 한 수동 재생성이 필요할 수 있습니다.

20
문제 20

You are migrating a vendor CRM database from a legacy SQL Server 2014 Enterprise instance running on a 3‑node VMware cluster with a Fibre Channel SAN to a single Cloud SQL for SQL Server instance in Google Cloud. Storage telemetry from the SAN shows peak read workloads reaching approximately 27,000 IOPS with read latency under 2 ms during quarterly reporting. You want to size the Cloud SQL instance to maximize read performance while keeping licensing costs minimal. What should you do?

이 옵션은 제시된 workload에 비해 compute와 storage 모두 너무 작습니다. 8 vCPU, 32 GB RAM, 600 GB SSD만으로는 가장 낮은 성능의 구성이며, 분기별 reporting 동안 peak read demand를 지속적으로 처리하기 어려울 가능성이 높습니다. 특히 storage allocation이 문제인데, Cloud SQL에서 SSD-backed IOPS capacity는 disk size에 따라 확장되며 600 GB로는 27,000 IOPS target에 필요한 충분한 headroom을 제공하지 못합니다. 더 저렴하긴 하지만 성능 requirement를 충족하지 못합니다.

이것이 최선의 정답인 이유는 SQL Server Standard를 사용하여 Enterprise보다 licensing costs를 낮게 유지하면서도, read-heavy CRM workload에 적합한 high-memory 16 vCPU / 104 GB 구성을 제공하기 때문입니다. 핵심 sizing 요소는 storage입니다. 800 GB SSD는 보기들 중 요구되는 performance tier를 충족하도록 의도된 가장 작은 옵션이므로, 제시된 Standard 구성 중 가장 비용 효율적입니다. 이 선택지는 compute, memory, storage의 균형을 맞추면서 disk capacity를 필요 이상으로 overprovisioning하지 않습니다. 성능과 최소 licensing cost를 모두 강조하는 시험 문제에서는, 이것이 제시된 read-performance requirement를 충족하도록 설계된 가장 경제적인 옵션입니다.

이 옵션은 충분한 성능을 제공할 가능성이 높지만, 가장 비용 효율적인 선택은 아닙니다. 1 TB SSD는 option B보다 더 많은 storage performance headroom을 제공하지만, 문제는 read performance를 최대화하면서 licensing costs를 최소로 유지하라고 요구합니다. 이는 불필요한 overprovisioning을 피해야 함을 의미합니다. B와 C 모두 SQL Server Standard와 동일한 compute shape를 사용하므로, C의 추가 storage는 최소 sizing 선택이 아닌데도 비용만 증가시킵니다. 따라서 비용 최적화가 requirement의 일부라면 C는 최선의 정답이 아닙니다.

이 옵션은 SQL Server Enterprise를 사용하므로 licensing cost가 크게 증가하며, licensing costs를 최소화해야 한다는 requirement와 직접적으로 충돌합니다. 또한 B와 C와 동일한 16 vCPU / 104 GB high-memory shape를 갖고 있지만, 500 GB SSD는 높은 read IOPS에 더 적합한 Standard 옵션들보다도 더 작습니다. Enterprise edition이 Cloud SQL storage performance limits를 본질적으로 제거하는 것은 아니므로, Enterprise에 더 많은 비용을 지불해도 핵심 sizing 문제는 해결되지 않습니다. 따라서 이 옵션은 더 비싸고 Standard 대안들보다도 덜 적절합니다.

문제 분석

핵심 개념: 이 문제는 Cloud SQL for SQL Server의 성능 sizing, 특히 storage size와 machine shape가 IOPS/latency에 어떤 영향을 주는지, 그리고 동시에 SQL Server licensing cost(Standard vs Enterprise)를 어떻게 균형 있게 고려하는지를 평가합니다. Cloud SQL에서 storage performance는 주로 기본 persistent disk 특성과 provisioned size(이는 IOPS/throughput ceiling에 영향을 줌)에 의해 결정되며, CPU/RAM은 query execution과 buffer cache hit rate에 영향을 줍니다. 정답인 이유: 측정된 peak read workload는 약 27,000 IOPS이며 latency는 2 ms 미만입니다. Cloud SQL에서 read performance를 최대화하려면 일반적으로 필요한 IOPS headroom을 충족할 수 있을 만큼 충분히 큰 SSD storage가 필요합니다. 이는 persistent disk SSD performance가 provisioned capacity에 따라 확장되고, per-GB IOPS limits 및 per-instance caps가 있기 때문입니다. Standard edition 옵션들 중에서 가장 큰 SSD(1 TB)는 가장 높은 달성 가능한 IOPS/throughput 범위를 제공하며, 분기별 reporting 동안 27k read IOPS를 지속할 가능성이 가장 높습니다. 또한 SQL Server Standard를 유지하면 Enterprise 대비 licensing cost를 최소화할 수 있습니다. 주요 기능 / 모범 사례: - latency에 민감한 OLTP/reporting burst에는 SSD를 선호합니다. - data volume만 기준으로 sizing하지 말고, peak IOPS와 headroom을 기준으로 storage를 sizing합니다. - SQL Server가 더 큰 buffer pool의 이점을 얻는 경우 High Memory shape를 사용합니다(핫 데이터를 caching하여 read performance 향상). 다만 storage IOPS가 여전히 제한 요소일 수 있음을 인식해야 합니다. - load testing으로 검증하고 Cloud SQL metrics(disk read ops, latency, CPU, buffer cache hit ratio)를 모니터링합니다. 흔한 오해: - vCPU를 늘리면 IOPS도 증가한다고 가정하는 것: CPU는 query processing에 도움이 되지만, storage IOPS limits가 더 큰 제약이 될 수 있습니다. - “성능”을 위해 Enterprise를 선택하는 것: Enterprise는 추가 기능(예: advanced HA/online operations)을 제공하지만 Cloud SQL storage limits를 본질적으로 제거하지는 않으며, licensing cost도 증가시킵니다. - SSD를 과소 sizing하는 것(예: 600–800 GB): 비용 효율적으로 보일 수 있지만 peak IOPS target을 충족하지 못할 수 있습니다. 시험 팁: 문제에서 IOPS/latency requirements를 제공하면, 먼저 이를 storage type과 size에 매핑한 다음 requirements를 충족하는 가장 작은 edition(Standard)을 선택하세요. 더 큰 SSD를 사용해 IOPS ceiling을 높이고, 필요한 기능이 명시적으로 Enterprise를 요구하는 경우에만 Enterprise를 선택하세요(예: 특정 HA/DR 또는 advanced SQL Server capabilities).

합격 후기(6)

J
J***********Nov 24, 2025

학습 기간: 1 month

Cloud Pass helped me master through practical and realistic questions. The explanations were clear and helped me understand.

혜
혜**Nov 21, 2025

학습 기간: 1 month

문제 다 풀고 시험쳤는데 유사한 문제가 많았어요. 다른 분들도 화이팅입니다!

L
L***********Nov 16, 2025

학습 기간: 2 weeks

I studied with Cloud Pass for two weeks, doing around 20 ~30 questions a day. The difficulty level was very similar to the real PCDBE exam. If you’re preparing for this certification, this app is a must have.

A
A************Nov 15, 2025

학습 기간: 1 month

Very close to the real exam. Thanks

P
P************Oct 30, 2025

학습 기간: 1 month

Being able to reset my progress and re-solve the hard questions helped me a lot. Passed!

모의고사

Practice Test #1

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

다른 GCP 자격증

Google Professional Cloud DevOps Engineer

Google Professional Cloud DevOps Engineer

Professional

Google Associate Cloud Engineer

Google Associate Cloud Engineer

Associate

Google Professional Cloud Network Engineer

Google Professional Cloud Network Engineer

Professional

Google Associate Data Practitioner

Google Associate Data Practitioner

Associate

Google Cloud Digital Leader

Google Cloud Digital Leader

Foundational

Google Professional Cloud Security Engineer

Google Professional Cloud Security Engineer

Professional

Google Professional Cloud Architect

Google Professional Cloud Architect

Professional

Google Professional Data Engineer

Google Professional Data Engineer

Professional

Google Professional Cloud Developer

Google Professional Cloud Developer

Professional

Google Professional Machine Learning Engineer

Google Professional Machine Learning Engineer

Professional

지금 학습 시작하기

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

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를 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.