연습 문제

문제 1

In your company’s Google Cloud organization, the qa-analytics-123 project contains 12 custom IAM roles that you must replicate exactly (same role IDs, titles, and permissions) to a new staging project stg-analytics-123 in the same organization, and you want to accomplish this in the fewest possible steps without promoting the roles to the organization level or manually re-selecting permissions; what should you do?

문제 분석

핵심 개념: 이 문제는 IAM custom role 관리와 이식성을 테스트합니다. Custom role은 project 또는 organization 범위로 스코프가 지정됩니다. Project-level custom role은 projects/PROJECT_ID/roles/ROLE_ID 아래에 존재하며 다른 project에서 자동으로 사용할 수 없습니다. 최소한의 노력으로 다른 project에 role을 “정확히” (동일한 role ID, title, permissions) 복제하려면 gcloud CLI의 role copy 기능을 사용해야 합니다. 정답이 맞는 이유: 옵션 A는 gcloud iam roles copy를 사용하여 qa-analytics-123의 각 custom role 정의를 stg-analytics-123으로 복사합니다. 이는 permissions를 수동으로 다시 선택하지 않고도 role 정의를 보존하는 가장 적은 단계의 접근 방식입니다. 또한 role을 project 스코프에 유지하므로 organization 레벨로 승격하지 말라는 요구사항을 충족합니다. Copy 작업은 기존 custom role을 다른 상위 리소스(다른 project)로 복제하는 이 사용 사례를 위해 설계되었습니다. 주요 기능 / 모범 사례: - Custom role은 메타데이터(roleId, title, description, stage)와 permissions 목록을 가진 리소스입니다. Copying은 인적 오류를 줄이고 환경(QA vs staging) 간 동등성을 보장합니다. - 소스에 대해 iam.roles.get, 대상 project에 대해 iam.roles.create(그리고 경우에 따라 iam.roles.update) 같은 적절한 permissions가 필요합니다. - Role ID는 대상 project 내에서 고유해야 합니다. “정확히” 복제한다는 것은 대상 project에 동일한 ID의 role이 아직 없음을 의미합니다. - Architecture Framework 관점(Security, Reliability, Operational Excellence)에서 automation/CLI 사용은 drift를 줄이고 환경 간 반복 가능성을 향상시킵니다. 흔한 오해: 일부는 project 간 공유를 위해 role을 organization으로 승격해야 한다고 가정합니다(옵션 B). 이는 불필요하며 요구사항을 위반합니다. 또 다른 일부는 Console에서 “clone role” 워크플로(옵션 C)를 찾지만, Console은 일반적으로 role 생성/편집이 필요하고, 수동 단계 없이 ID를 보존하며 project에서 project로 진정한 bulk/clone 기능을 제공하지 않을 수 있습니다. 시험 팁: - 스코프 경계를 기억하세요: project custom role은 copy 또는 재생성하지 않는 한 project 간 재사용이 불가능합니다. - 반복 가능한 IAM 구성을 위해 gcloud/automation을 선호하여 permission 선택 실수를 피하세요. - 문제가 “fewest steps”와 “replicate exactly”를 강조하면, 수동 재생성보다 직접적인 copy/export-import 메커니즘을 찾으세요.

문제 2

You plan to host a geospatial tile-rendering backend on Compute Engine; traffic averages 150 concurrent render jobs but spikes to 1,500 during quarterly map releases, and customers must be able to submit jobs 24/7 without interruption or CPU throttling. Your SLO requires 99.9% availability across at least two zones in us-central1, and you want to follow Google-recommended practices so capacity scales automatically without manual intervention. What should you do?

문제 분석

핵심 개념: 이 문제는 Managed Instance Groups (MIGs), 멀티 존 배포, 그리고 autoscaling을 사용한 Compute Engine 확장성과 고가용성을 평가합니다. 또한 수동 개입을 피하고 가용성 SLO를 충족하는 이해도를 간접적으로 테스트합니다. 정답이 맞는 이유: us-central1의 regional (multi-zone) Managed Instance Group은 최소 두 개 존에 걸쳐 인스턴스를 분산할 수 있으므로, 단일 존 장애가 발생해도 서비스가 중단되지 않아 적절한 health checks 및 load balancing과 함께 99.9% 가용성 목표를 지원합니다. 평균 CPU utilization 기반 autoscaling은 분기별 스파이크(동시 작업 1,500개) 동안 자동으로 인스턴스를 추가하고, 정상 부하(150개 작업)에서는 다시 축소하여 수동 개입 없이 자동 용량 관리를 요구사항에 맞게 충족합니다. 주요 기능 / 구성: 1) “최소 두 개 존에 걸쳐” 요구사항을 만족하기 위해 us-central1의 두 개(또는 그 이상) 존을 아우르는 regional MIG. 2) 평균 CPU utilization(또는 작업이 큐에 쌓이는 경우 queue depth 같은 custom metric) 기반 autoscaler 정책으로 자동 scale out/in. 3) 일관된 VM 구성과 빠르고 반복 가능한 확장을 보장하는 instance template. 4) 비정상 VM을 자동으로 재생성하는 health checks 및 autohealing. 5) 중단을 피하기 위해 non-preemptible VMs(표준 on-demand)를 사용하고, “CPU throttling 없음”이 엄격한 요구사항이라면 overcommitted/shared-core machine types는 피합니다. 흔한 오해: “standalone instances”를 언급하거나 “high CPU를 보면 증가” 같은 옵션은 수동 운영을 의미하므로 자동 확장 요구사항을 위반합니다. 또한 단순히 high-CPU 머신으로 리사이징하는 것은 급격한 스파이크를 잘 해결하지 못하며, 여전히 프로비저닝 부족이 발생하거나 교체 과정에서 중단을 유발할 수 있습니다. 시험 팁: (1) 트래픽 변동, (2) 자동 scaling 필요, (3) 멀티 존 가용성 요구사항을 보면, 기본 권장 패턴은 autoscaling과 autohealing을 갖춘 Managed Instance Group(종종 regional)입니다. 작업 처리 워크로드에서는 CPU가 최선의 scaling 신호인지 고려해야 하지만, ACE 시험에서는 queue 기반 metric이 명시적으로 제시되지 않는 한 “평균 CPU utilization 기반 autoscaling”이 정석 답안입니다.

문제 3

You manage two named gcloud configurations on your workstation—dev-eu (active) and prod-us (inactive). Without changing the active configuration or modifying your kubeconfig, you must verify which Google Kubernetes Engine (GKE) cluster (project ID, location, and cluster name) is configured in prod-us using the fewest possible commands. What should you do?

문제 4

You run three Compute Engine virtual machines in the us-central1 region that listen for TCP traffic on port 25565 and must enforce per-client IP rate limits. You need to make this service publicly accessible on the internet via a Google Cloud load balancer while preserving the original client source IP; which load balancer should you use?

문제 분석

핵심 개념: 이 문제는 Google Cloud load balancing 유형, 특히 원래 클라이언트 source IP가 backend에 보존되는지 여부를 평가합니다. source IP 보존은 backend가 애플리케이션 또는 호스트 firewall 수준에서 클라이언트 IP별 rate limit을 적용해야 할 때 중요합니다. 정답인 이유: external TCP/UDP Network Load Balancer (passthrough)는 regional L4 load balancer로, 연결을 proxy하지 않고 packet을 backend VM으로 전달합니다. “passthrough”이므로 backend VM은 실제 클라이언트 source IP(google proxy IP가 아님)를 확인합니다. 이를 통해 TCP port 25565를 수신하는 Compute Engine 인스턴스에서 정확한 클라이언트 IP별 rate limit을 적용할 수 있습니다. 또한 인터넷에서 공개적으로 접근 가능해야 한다는 요구사항에도 부합합니다. 주요 기능 / 구성 참고 사항: - us-central1에서 TCP:25565에 대한 forwarding rule을 가진 external passthrough Network Load Balancer를 사용합니다. - backend는 일반적으로 health check가 포함된 unmanaged instance group(또는 managed instance group)입니다. - regional이므로 “us-central1에 있는 3개의 VM”과 정렬됩니다. - source IP 보존은 passthrough NLB의 고유 특성이며, 별도의 special header가 필요하지 않습니다. - 필요에 따라 load balancer 및 health check range에서의 트래픽을 허용하도록 firewall rule을 설정합니다. 흔한 오해: 많은 응시자가 TCP Proxy 또는 SSL Proxy load balancer를 “external”이고 TCP를 지원한다는 이유로 선택합니다. 하지만 이는 proxy 기반 load balancer입니다. 즉, Google edge에서 클라이언트 연결을 종료(terminate)하고 backend로 새 연결을 생성하므로, backend는 네트워크 계층에서 원래 클라이언트 IP를 보지 못합니다. 일부 proxy LB는 특정 제품에서 PROXY protocol을 통해 클라이언트 IP를 제공할 수 있지만, 시험에서 source IP를 보존하여 rate limiting을 해야 한다는 표준 기대는 passthrough Network Load Balancer를 사용하는 것입니다. 시험 팁: “원래 클라이언트 source IP 보존” 또는 “backend가 클라이언트 IP를 봐야 함” 같은 요구사항이 보이면 proxy(TCP/SSL Proxy, HTTP(S))가 아니라 passthrough(Network Load Balancer)를 떠올리세요. 또한 범위를 매핑하세요: external + regional L4 + non-HTTP custom port 조합은 external TCP/UDP Network Load Balancer (passthrough)를 강하게 시사합니다.

문제 5

Your telemedicine platform must retain daily anonymized diagnostic image bundles in Cloud Storage for 24 months (about 2 TB per month, ~100 GB per object), and compliance reviewers only read a small subset during quarterly audits (4 times per year), so to minimize total cost while allowing occasional reads, which Cloud Storage class should you choose?

문제 분석

핵심 개념: 이 문제는 Google Cloud Storage (GCS) storage classes와 접근 빈도 및 보존 기간을 기반으로 총비용이 가장 낮은 선택지를 고르는 방법을 평가합니다. GCS에서 비용은 GB-월당 저장 단가, retrieval (read) 요금, 그리고 early deletion minimum storage duration 요금의 조합으로 구성됩니다. 정답이 맞는 이유: Coldline Storage는 분기당 최대 1회 접근되는 데이터를 위해 설계되어 있으며, 제시된 패턴(컴플라이언스 검토자가 분기별 감사에서 일부만 읽음, 연 4회)과 일치합니다. 데이터는 24개월 보존되어야 하므로 Coldline의 minimum storage duration(90일)을 충분히 초과하여 early deletion penalties를 피할 수 있습니다. 매월 약 2 TB가 유입되고 객체가 큰 편(각 ~100 GB)이므로, 플랫폼은 Nearline/Regional/Multi-Regional 대비 Coldline의 더 낮은 저장 비용의 이점을 누리면서도 감사 시점에 필요한 간헐적 읽기를 허용할 수 있습니다. 주요 기능 / Best Practices: - storage class 선택은 접근 빈도에 의해 결정되어야 합니다: Standard/Regional/Multi-Regional은 빈번한 접근, Nearline은 월 1회 수준, Coldline은 분기 1회 수준, Archive는 연 1회/매우 드문 접근. - Coldline은 Nearline/Standard보다 retrieval 및 operation 비용이 더 높지만, 읽기가 드물다면 그 비용은 상쇄됩니다. - Object Lifecycle Management를 사용해 보존을 강제하고, 필요 시 객체를 전환(예: Standard -> Coldline)할 수 있습니다(ingestion 워크플로우가 잠시 “hot” storage를 요구하는 경우). - bucket location은 storage class와 별개로(compliance 및 latency에 따라 region/dual-region/multi-region) 고려해야 하며, 이 문제는 비용을 위한 class에 초점을 둡니다. 흔한 오해: - 감사가 연중 여러 번 발생하므로 Nearline이 적절해 보일 수 있지만, Nearline은 대략 월 1회 접근에 최적화되어 있어 분기별 읽기라면 Coldline이 일반적으로 총비용이 더 저렴합니다. - Regional/Multi-Regional을 infrequent access를 위한 “class”로 오해하는 경우가 많지만, 이는 active data 및 availability/latency 요구를 위한 더 높은 저장 비용의 Standard storage 제공 방식입니다. Exam Tips: 접근 빈도 매핑을 암기하세요: Nearline(~월간), Coldline(~분기), Archive(~연간). 항상 minimum storage duration(Nearline 30일, Coldline 90일, Archive 365일)을 확인하고 retrieval 요금을 함께 고려하세요. 장기 보존과 드문 읽기라면, 접근 요구를 충족하면서 early deletion penalties를 피할 수 있는 범위에서 가장 “cold”한 class를 선택하세요.

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

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

문제 6

Your broadcast company runs 18 transcoding servers on-premises in subnet 172.20.32.0/20 inside a locked-down production VLAN. These servers must read and write objects to Cloud Storage buckets in the prod-media project for daily ingest (up to 800 GB/day), but company policy forbids assigning public IPs to the servers and blocks any outbound internet access; only site-to-site connectivity over an existing Cloud VPN (up to 1 Gbps) is allowed, with a Dedicated Interconnect scheduled within 60 days. Security requires that all Google API traffic stay on private paths and be restricted to Google-controlled IP ranges, and you may not deploy public NAT egress or rely on hard-coded public IPs. Following Google-recommended practices, how should you provide the on-prem servers with access to Cloud Storage while keeping them off the public internet?

문제 분석

핵심 개념: 이 문제는 Cloud VPN 또는 Interconnect를 통해 Restricted Google APIs를 사용하여 온프레미스 시스템에서 Cloud Storage와 같은 Google APIs에 비공개로 액세스하기 위한 권장 하이브리드 패턴을 테스트합니다. 목표는 트래픽이 public internet을 거치지 않도록 하고, public NAT 또는 external IP 의존성을 피하며, 대상지를 Google이 제어하는 IP 범위로 제한하는 것입니다. 정답인 이유: 옵션 D는 온프레미스에서 Google APIs에 액세스하기 위한 Google 권장 방식과 일치합니다. 즉, VPC에 대한 하이브리드 연결을 설정하고, Cloud Router를 사용해 경로를 교환하며, restricted.googleapis.com VIP 범위(199.36.153.4/30)가 private connection을 통해 도달 가능하도록 만들고, 필요한 Google API 이름이 restricted.googleapis.com 또는 restricted VIP로 해석되도록 DNS를 구성합니다. 이렇게 하면 Cloud Storage에 대한 요청이 public internet이 아니라 VPN/Interconnect를 통해 전달되며, 동시에 API 액세스를 제한된 Google 서비스 집합으로 한정할 수 있습니다. 이는 public IP 없음, internet egress 없음, 하드코딩된 public service IP 허용 목록 없음이라는 요구 사항을 충족합니다. 주요 기능/구성: 1) 하이브리드 연결: 현재는 기존 Cloud VPN을 사용하고 이후에는 Dedicated Interconnect를 사용하며, Cloud Router가 동적 경로 교환을 처리합니다. 2) 라우팅: 온프레미스 네트워크가 199.36.153.4/30에 대한 경로를 학습하여 restricted Google APIs용 트래픽이 private link를 통해 전송되도록 해야 합니다. 3) DNS: private DNS override 또는 forwarding을 사용하여 워크로드에 필요한 특정 Google API hostname(예: Cloud Storage endpoint)이 restricted.googleapis.com 또는 restricted VIP로 해석되도록 하면서, 유효한 TLS/SNI 동작을 유지합니다. 4) 보안 관점: 트래픽은 Google이 제어하는 VIP로의 private connectivity 상에 유지되며, public NAT가 없고, 온프레미스 서버에 external IP가 없으며, 변경될 수 있는 public endpoint 주소에 의존하지 않습니다. 흔한 오해: 흔한 실수 중 하나는 Google Cloud의 proxy VM에 단순히 도달할 수 있으면 API 액세스가 비공개가 된다고 생각하는 것입니다. 하지만 proxy도 여전히 Google APIs로 가는 규정을 준수하는 경로가 필요하며, 종종 불필요한 복잡성만 추가합니다. 또 다른 오해는 storage.googleapis.com의 현재 public IP를 허용 목록에 추가하는 것이 괜찮다고 생각하는 것이지만, 해당 주소는 고객이 관리하는 고정 허용 목록으로 취급하도록 의도된 것이 아니며 여전히 internet egress가 필요합니다. 또한 응시자는 DNS 변경을 지나치게 일반화할 수 있습니다. 올바른 접근 방식은 모든 googleapis.com 이름에 대한 무차별적인 wildcard CNAME이 아니라, Google API 이름에 대한 대상 지정 private resolution입니다. 시험 팁: 문제에서 온프레미스 호스트, internet egress 없음, public IP 없음, 그리고 private path를 통한 Google APIs 액세스만 언급된다면, restricted.googleapis.com과 하이브리드 연결 및 199.36.153.4/30에 대한 경로 광고를 떠올리세요. Private Google Access는 주로 external IP가 없는 Google Cloud 리소스를 위한 것이고, 온프레미스의 private API 액세스는 적절한 라우팅과 DNS를 갖춘 VPN 또는 Interconnect를 통해 달성된다는 점을 기억하세요. 또한 Google이 제어하는 IP 범위에 대한 표현이 나오면, 이는 proxy나 public endpoint 허용 목록보다 restricted VIP 패턴을 강하게 시사합니다.

문제 7

A logistics company operates three Google Cloud projects named north-1, south-1, and west-1, each running about 20 Compute Engine VMs. The SRE team needs a single pane of glass to monitor CPU utilization, memory usage, and Persistent Disk throughput across all three projects without switching contexts, and they want to set it up in under an hour using built-in capabilities and IAM. What should you do?

문제 분석

핵심 개념: 이 문제는 여러 Google Cloud 프로젝트 전반에서 중앙집중식 관측 가능성을 제공하기 위한 Cloud Monitoring “workspace/metrics scope”(이전 Stackdriver Workspace)와, 해당 프로젝트들 전반의 metrics를 보기 위해 필요한 IAM을 테스트합니다. metrics scope를 사용하면 여러 “monitored projects”의 metrics와 dashboards를 한 곳(단일 창, single pane of glass)으로 집계할 수 있습니다. 정답이 맞는 이유: 옵션 D만이 중앙집중식 Monitoring 뷰를 생성합니다. host project(north-1)에 Cloud Monitoring workspace(metrics scope)를 만들고 south-1과 west-1을 monitored projects로 추가하면, SRE는 (host project에서) Cloud Monitoring을 한 번만 열어 세 프로젝트 전체의 metrics를 프로젝트 컨텍스트 전환 없이 조회/그래프화할 수 있습니다. 이는 내장 기능과 IAM을 사용해 빠르게 설정하라는 요구사항과 일치합니다. 주요 기능 / 구성: 1) Metrics scope: host project가 “scoping project”가 됩니다. 다른 프로젝트를 추가하면 단일 UI에서 cross-project metrics, dashboards, alerting policies, uptime checks를 사용할 수 있습니다. 2) IAM: 사용자는 여전히 각 monitored project에서 metrics를 보기 위한 권한(일반적으로 roles/monitoring.viewer)과 관련 리소스에 대한 접근 권한이 필요합니다. metrics scope는 집계를 제공하고, IAM은 인가를 제공합니다. 3) Built-in metrics: Compute Engine의 CPU utilization과 Persistent Disk throughput은 기본으로 제공됩니다. memory usage는 VM에 Ops Agent(또는 legacy agent)를 설치해야 합니다. 다만 이 문제는 모니터링 설정 방식에 초점이 있으며, cross-project 조회를 위한 올바른 메커니즘은 여전히 metrics scope입니다. 흔한 오해: - API를 단순히 활성화하거나 Monitoring Viewer를 부여하는 것(옵션 B)은 통합 뷰를 만들지 못하고, 프로젝트별 접근만 허용합니다. 사용자는 콘솔에서 여전히 프로젝트를 전환해야 합니다. - charts를 공유하는 것(옵션 A)은 표준적인 “single pane of glass” 접근이 아니며 유지보수가 번거롭습니다. 또한 통합된 탐색 경험을 제공하지 않습니다. - 프로젝트를 하나씩 보는 것(옵션 C)은 “컨텍스트 전환 없이”라는 요구사항을 명시적으로 위반합니다. 시험 팁: “여러 프로젝트를 한 곳에서 모니터링”이면 “Cloud Monitoring metrics scope/workspace”를 떠올리세요. “누가 metrics를 볼 수 있는가”는 각 프로젝트의 IAM을 떠올리면 됩니다. 또한 어떤 metrics가 native(CPU/disk)이고 어떤 것이 agent 기반(memory)인지도 기억하세요. ACE 시나리오에서 가장 빠른 내장 cross-project 모니터링 설정은: 한 프로젝트에 metrics scope를 만들고 다른 프로젝트들을 monitored projects로 추가하는 것입니다.

문제 8

At a logistics company, you plan to run a one-time BigQuery SQL that joins two US multi-region tables (shipments ~1.6 TB and scan_events ~400 GB) and could return about 50 million rows; you use on-demand pricing and must estimate the cost before running the query. You are allowed to use the bq command-line tool but cannot change the billing model or pre-materialize data. What should you do?

문제 분석

핵심 개념: 이 문제는 on-demand(analysis) 요금제에서 BigQuery 비용을 추정하는 방법과, bq CLI를 통해 BigQuery의 dry run 기능을 사용하여 쿼리 비용을 안전하게 추정하는 방법을 평가합니다. on-demand 요금제에서 BigQuery는 주로 쿼리가 처리한 바이트 수(읽은 바이트 수)에 대해 과금하며, 반환된 행 수에 대해 과금하지 않습니다. 정답이 맞는 이유: BigQuery dry run은 쿼리를 실행하지 않고 파싱 및 계획을 수립한 뒤, 총 처리 바이트 수에 대한 추정치를 반환합니다. 이는 대규모 테이블에 대해 일회성 join을 실행하기 전에 on-demand 쿼리 비용을 추정하는 데 정확히 필요한 정보입니다. bq에서는 dry run(예: bq query --dry_run --use_legacy_sql=false '...')을 실행하고 “totalBytesProcessed” 값을 확인할 수 있습니다. 그런 다음 처리 바이트를 TB로 변환하고 on-demand TB당 가격을 곱하면 됩니다(또는 Google Cloud Pricing Calculator 사용). 이 접근은 모든 제약을 충족합니다: bq를 사용하고, billing model을 변경하지 않으며, 데이터를 사전에 materialize할 필요가 없습니다. 주요 기능 / 모범 사례: Dry run은 처리 바이트 수를 추정하고 SQL을 검증할 수 있는 무비용 방법을 제공합니다. BigQuery on-demand 과금은 partition pruning, clustering, column projection을 고려한 후의 처리 바이트 수를 기준으로 합니다. 테이블이 US multi-region에 있으므로 cross-location 쿼리 이슈가 없습니다. 결과가 5천만 행이 될 가능성은 출력 크기와 클라이언트 측 처리에 영향을 줄 수 있지만, on-demand 쿼리의 주요 과금 요소에는 영향을 주지 않습니다. 흔한 오해: “bytes returned”와 “bytes processed”를 혼동하기 쉽습니다. BigQuery의 on-demand analysis 비용은 결과 세트 크기가 아니라 스캔/처리된 바이트 수에 의해 결정됩니다. 또 다른 오해는 행 수를 세는 것(SELECT COUNT(*))이 스캔 비용을 나타낸다는 것인데, 그렇지 않습니다. 스캔 비용은 읽은 바이트 수와 쿼리 플랜 최적화에 따라 달라집니다. 시험 팁: 비용 추정 문제에서는 다음을 기억하세요: on-demand BigQuery = 처리된 TB당 비용. Dry run으로 totalBytesProcessed를 얻으세요. 또한 analysis 비용(처리 바이트)과 다른 잠재 비용(storage, BI Engine, exports)을 구분하세요. 여기서는 후자가 핵심이 아닙니다. 이는 Google Cloud Architecture Framework의 비용 최적화 원칙과도 일치합니다: 대규모 워크로드를 실행하기 전에 측정하고 추정하라.

문제 9

An independent animation studio occasionally renders 4K scenes on a GKE cluster you manage; their renderer requires NVIDIA GPUs, each render job runs 10–16 hours with no checkpoints (non-restartable), and work arrives only 2–3 days per month; you must minimize cost while ensuring these long-running jobs are not interrupted and that capacity scales automatically when work arrives. What should you do?

문제 분석

핵심 개념: 이 문제는 드물게 발생하고 bursty한 GPU 워크로드가 중단 없이 완료되어야 할 때, 가장 비용 효율적인 GKE scaling 메커니즘을 선택하는 것에 관한 것입니다. 핵심은 작업이 queue에 들어왔을 때만 GPU node를 프로비저닝하고, 동시에 장시간 실행되며 checkpoint가 불가능한 워크로드를 종료시킬 수 있는 인프라 선택지는 피하는 것입니다. 정답인 이유: 렌더링 작업은 한 달에 2~3일만 들어오므로, 가장 저렴한 접근 방식은 idle 상태일 때 GPU node를 계속 실행하지 않는 것입니다. Node auto-provisioning은 GPU를 요청하는 unschedulable pod에 대응하여 GKE가 적절한 크기의 node pool을 자동으로 생성하고, 더 이상 필요하지 않을 때 해당 node를 제거할 수 있게 해줍니다. 작업은 중단될 수 없으므로, 이러한 auto-provisioned node는 Spot/Preemptible 인스턴스가 아니라 standard non-preemptible VM이어야 합니다. 주요 기능 / 구성: - pending GPU 워크로드를 위해 cluster가 자동으로 node를 생성할 수 있도록 GKE node auto-provisioning을 활성화합니다. - 렌더 pod가 필요한 NVIDIA GPU resource를 요청하도록 하여 GKE가 specialized node가 필요하다는 것을 알 수 있게 합니다. - 10~16시간 렌더링 중 비자발적 종료를 피하기 위해 Spot/Preemptible이 아닌 standard VM 기반 node를 사용합니다. - 작업 완료 후 사용되지 않는 GPU node가 다시 scale down되도록 하여 월간 비용을 최소화합니다. 일반적인 오해: - min=1인 전용 GPU node pool은 안정적이지만, 매달 며칠만 실행되는 워크로드에 대해 가장 저렴한 옵션은 아닙니다. - Vertical Pod Autoscaler는 node provisioning이나 GPU capacity 문제를 해결하지 않으며, pod resource request만 조정합니다. - Preemptible 또는 Spot GPU는 비용 절감 측면에서 매력적으로 보일 수 있지만, 언제든 회수될 수 있으므로 재시작 불가능한 작업에는 적합하지 않습니다. 시험 팁: - 드물게 실행되는 batch 워크로드의 경우, 가능하면 scale-to-zero를 허용하는 autoscaling 메커니즘을 우선 고려하세요. - checkpoint가 불가능한 작업의 경우, Spot/Preemptible 선택지는 즉시 제외하세요. - VPA 같은 pod 수준 scaling 도구와 Cluster Autoscaler 및 node auto-provisioning 같은 인프라 수준 scaling 도구를 구분하세요. - 문제에서 automatic scaling과 idle 비용 최소화를 모두 강조한다면, specialized node를 필요할 때만 프로비저닝하는 옵션을 찾으세요.

문제 10

You are responsible for a Google Kubernetes Engine (GKE) cluster named "staging-ops" in the project "retail-ops-9912" located in the zone "europe-west1-b". You have just installed the Cloud SDK on a new admin VM and completed gcloud init to authenticate. You want all future CLI commands to default to targeting this specific cluster without having to specify the cluster name each time. What should you do?

문제 분석

핵심 개념: 이 문제는 Google Kubernetes Engine 액세스를 위한 Cloud SDK (gcloud) 구성 관리에 대해 테스트합니다. GKE 워크플로우에서는 일반적으로 gcloud를 사용해 기본값(프로젝트, 리전/존, 클러스터)을 설정한 다음 gcloud container clusters get-credentials를 사용해 kubeconfig를 채워 kubectl이 올바른 클러스터 컨텍스트를 대상으로 하도록 합니다. 정답이 맞는 이유: 옵션 A는 gcloud의 내장 구성 시스템을 사용합니다: gcloud config set container/cluster staging-ops. 이는 활성 gcloud 구성에서 영구 속성을 설정하여, 이후 gcloud container 명령이 --cluster를 반복해서 전달하지 않아도 클러스터 이름을 추론할 수 있게 합니다. 실제로는 gcloud가 클러스터를 고유하게 식별할 수 있도록 container/zone(또는 container/location)과 core/project(예: retail-ops-9912 및 europe-west1-b)도 설정되어 있는지 확인해야 합니다. 이는 관리자 워크스테이션/VM에서 일관된 기본값을 설정함으로써 “클라우드 솔루션 환경 설정”에 대한 모범 사례와 일치합니다. 주요 기능 / 모범 사례: - gcloud configurations는 속성을 명명된 프로필(예: default)에 저장하여, 반복 가능한 관리자 환경을 가능하게 합니다. - 일반적인 관련 속성: core/project, compute/zone, container/cluster, container/use_application_default_credentials. - kubectl 사용을 위해서는 일반적으로 다음을 실행합니다: gcloud container clusters get-credentials staging-ops --zone europe-west1-b --project retail-ops-9912, 이는 kubeconfig 컨텍스트를 설정합니다. 하지만 이 문제는 구체적으로 CLI 명령의 기본값 설정에 관한 것이며, 이는 gcloud config로 처리됩니다. - Architecture Framework 관점(Operational Excellence)에서 기본값을 설정하면 인적 오류를 줄이고 반복 가능성을 향상시킵니다. 흔한 오해: 많은 응시자가 “gcloud의 기본 클러스터”와 “kubectl의 기본 컨텍스트”를 혼동합니다. container/cluster를 설정하면 gcloud 명령에 도움이 되지만, kubectl 기본값은 kubeconfig 컨텍스트(get-credentials 및 kubectl config use-context로 설정됨)에 의해 제어됩니다. 또한 ~/.gcloud에 사용자 정의 파일을 만드는 것은 Cloud SDK가 속성을 저장하는 방식이 아닙니다. 이는 gcloud가 관리하는 내부 구성 파일을 사용합니다. 시험 팁: - “향후 gcloud 명령이 X를 기본값으로 사용하게 하라”를 보면 gcloud config set을 떠올리세요. - “kubectl이 클러스터를 가리키게 하라”를 보면 gcloud container clusters get-credentials 및 kubectl config use-context를 떠올리세요. - 여러 프로젝트/리전에 동일한 이름의 클러스터가 있을 때 모호함을 피하기 위해 프로젝트와 위치 기본값이 설정되어 있는지 항상 확인하세요.

Practice Test #1

3중 AI 검증 답안 및 해설

연습 문제

합격 후기(11)

다른 모의고사

Practice Test #2

지금 학습 시작하기