CloudPass LogoCloud Pass
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
Certifications
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
Google Associate Cloud Engineer
Google Associate Cloud Engineer

Practice Test #1

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

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

AI 기반

3중 AI 검증 답안 및 해설

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

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

기출 문제

1
문제 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?

정답입니다. gcloud iam roles copy는 custom role 정의를 한 parent(project)에서 다른 parent로 복제하기 위해 의도된 기능입니다. permissions와 메타데이터를 보존하며, destination을 project 레벨(stg-analytics-123)로 유지하여 role을 organization으로 승격하지 말라는 요구사항을 충족할 수 있습니다. 또한 permissions를 수동으로 다시 선택하는 과정을 피하여 오류와 단계를 최소화합니다.

오답입니다. Role을 organization으로 복사하면 스코프가 project-level에서 org-level로 변경되어 모든 project에서 role을 사용할 수 있게 됩니다. 문제는 role을 organization 레벨로 승격하지 말라고 명시합니다. Org-level role은 표준화에 유용할 수 있지만, 제시된 제약을 위반하며 여기서 가장 적절한 조치가 아닙니다.

오답입니다. Google Cloud Console은 “replicate exactly” 및 “fewest steps” 요구사항을 충족하는, “다른 project에서 동일한 role ID로 role을 clone/copy”하는 간단한 워크플로를 일관되게 제공하지 않습니다. 기존 role을 기반으로 만들 수 있더라도, 일반적으로 role마다 편집 및 저장을 해야 하며, project 간 정확한 ID 보존은 Console의 주요 경로가 아닙니다.

오답입니다. 12개의 role을 수동으로 생성하고 permissions를 다시 선택하는 것은 시간이 많이 들고 오류가 발생하기 쉬우며, 수동 permission 선택을 피하라는 요구사항과 정면으로 배치됩니다. 이 접근은 QA와 staging 간 구성 drift 위험을 높이며, 반복 가능한 IAM 구성에 대한 모범 사례에도 부합하지 않습니다.

문제 분석

핵심 개념: 이 문제는 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
문제 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?

CPU alert threshold가 있는 여러 standalone VM은 용량을 추가하기 위해 여전히 수동 조치(또는 언급되지 않은 스크립팅)가 필요합니다. 또한 standalone instances는 managed autohealing과 instance templates를 통한 일관된 롤아웃이 없습니다. Google 권장 자동 scaling 관행 요구사항을 충족하지 못하며, us-central1에서 최소 두 개 존에 걸친 멀티 존 고가용성을 명시적으로 보장하지도 않습니다.

VM을 high-CPU 인스턴스로 교체하는 것은 vertical scaling 접근으로, 더 느리고 잠재적으로 중단을 유발합니다(인스턴스 교체/재시작). 또한 수동 개입에 의존하며, 멀티 존 복원력이나 managed autohealing을 본질적으로 제공하지 않습니다. vertical scaling은 autoscaling으로 인스턴스 수를 수평 확장하는 것만큼 10배 스파이크를 효과적으로 처리하지 못합니다.

instance group을 사용하는 것은 더 가깝지만, “high CPU utilization을 볼 때마다” 인스턴스를 늘린다고 되어 있어 수동이며 개입 없이 자동 scaling 요구사항을 위반합니다. 또한 두 개 존에 걸친다는 점을 명시하지 않습니다. zonal instance group은 us-central1에서 최소 두 개 존에 걸친 가용성 SLO 요구사항을 충족하지 못합니다.

두 개 존에 걸친 managed instance group(regional MIG)은 고가용성과 탄력성을 위한 권장 Compute Engine 패턴입니다. 평균 CPU utilization 기반 autoscaling은 수동 작업 없이 수요 스파이크에 맞춰 인스턴스를 자동으로 추가/제거합니다. MIG는 또한 autohealing, rolling updates, 그리고 instance templates를 통한 일관된 구성을 지원하여 Google 모범 사례 및 명시된 99.9% 멀티 존 SLO에 부합합니다.

문제 분석

핵심 개념: 이 문제는 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
문제 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?

정답입니다. `gcloud config configurations describe prod-us`는 named configuration에 저장된 속성을 활성화하지 않고 확인합니다. 이는 활성 configuration을 변경하지 않아야 한다는 요구사항을 충족하며 kubeconfig도 전혀 건드리지 않습니다. 일반적으로 GKE cluster name을 직접 보여주지는 않지만, prod-us environment와 연결된 project 및 location 설정을 확인하는 가장 적절하고 가장 적은 명령 수의 방법입니다.

오답입니다. `gcloud config configurations activate prod-us`는 활성 configuration을 변경하며, 이는 문제에서 명시적으로 금지하고 있습니다. 이후 `gcloud config list`로 해당 configuration의 속성을 볼 수는 있지만, 이 접근 방식은 요구사항을 위반하고 필요 이상으로 많은 명령을 사용합니다. 시험에서는 프롬프트가 읽기 전용 확인을 요구할 때 상태를 변경하는 선택지는 제외해야 합니다.

오답입니다. `kubectl config get-contexts`는 gcloud named configurations가 아니라 kubeconfig의 Kubernetes contexts를 읽습니다. 문제는 비활성 gcloud configuration인 prod-us에 대해 묻고 있으므로, 이 작업에서 kubeconfig는 올바른 정보 출처가 아닙니다. 이 명령이 읽기 전용이기는 하지만, prod-us에 어떤 속성이 설정되어 있는지 직접 알려주지는 않습니다.

오답입니다. `kubectl config use-context`는 현재 Kubernetes context를 변경하므로 kubeconfig 상태를 수정하며 요구사항을 위반합니다. 또한 kubectl contexts는 gcloud named configurations와 별개이므로, context를 전환해도 prod-us에 저장된 내용을 알 수 없습니다. 이 선택지는 상태를 변경할 뿐 아니라 잘못된 configuration system을 참조합니다.

문제 분석

핵심 개념: 이 문제는 gcloud named configurations와 kubectl kubeconfig contexts의 차이를 테스트합니다. gcloud configuration은 project, compute region, compute zone과 같은 CLI 속성을 저장하며, 비활성 configuration도 활성화하지 않고 직접 확인할 수 있습니다. kubectl 명령은 kubeconfig를 읽으며, 이는 gcloud named configurations와는 별개입니다. 정답인 이유: 요구사항은 활성 configuration을 변경하지 않고, kubeconfig도 수정하지 않으면서 비활성 prod-us configuration을 확인하는 것입니다. `gcloud config configurations describe prod-us` 명령은 단일 읽기 전용 단계로 해당 named configuration을 직접 읽는 유일한 선택지입니다. 이 명령을 사용하면 prod-us와 연결된 project 및 location 관련 속성을 확인할 수 있으며, 이는 gcloud configuration만으로 의도된 GKE environment를 식별할 수 있는 가장 적절한 방법입니다. 주요 기능 / 모범 사례: - 비활성 configuration을 안전하게 확인하려면 `gcloud config configurations describe NAME`를 사용합니다. - gcloud configurations와 kubeconfig는 용도가 다르며 서로 독립적으로 관리된다는 점을 기억하세요. - GKE cluster name은 일반적으로 표준 gcloud configuration 속성으로 저장되지 않으며, 보통 `gcloud container clusters get-credentials` 실행 후 kubeconfig contexts에 반영됩니다. 흔한 오해: 흔한 실수 중 하나는 kubectl contexts가 비활성 gcloud configuration에 무엇이 들어 있는지 알려준다고 생각하는 것입니다. 또 다른 실수는 gcloud configuration이 본질적으로 GKE cluster name을 저장한다고 가정하는 것입니다. 실제로는 보통 선택된 cluster 자체가 아니라 project와 location 기본값을 저장합니다. 읽기 전용 describe 명령이 있는데도 확인만 하려고 configuration을 활성화하는 것은 불필요합니다. 시험 팁: - 문제에서 활성 configuration을 변경하지 말라고 하면 `activate`는 피하세요. - kubeconfig를 수정하지 말라고 하면 kubectl context를 전환하는 명령은 피하세요. - 시험에서는 요청된 configuration을 직접 확인하는 최소한의 읽기 전용 명령을 선택하세요.

4
문제 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?

정답입니다. external TCP/UDP Network Load Balancer (passthrough)는 regional L4 load balancer로, 연결을 종료하지 않고 packet을 backend로 직접 전달합니다. proxy가 아니므로 backend VM은 원래 클라이언트 source IP를 수신하여 클라이언트 IP별 rate limiting을 가능하게 합니다. 25565 같은 임의의 TCP port를 지원하며 external forwarding rule을 통해 서비스를 공개적으로 접근 가능하게 만듭니다.

오답입니다. TCP Proxy Load Balancer는 proxy 기반 external load balancer입니다. Google edge에서 클라이언트 TCP session을 종료한 뒤 backend로 별도의 연결을 엽니다. 그 결과 backend는 일반적으로 실제 클라이언트 IP가 아니라 Google proxy source IP를 보게 되어, VM에서 source address 기반의 클라이언트 IP별 rate limiting이 깨집니다.

오답입니다. SSL Proxy Load Balancer도 proxy 기반이며 L4에서 SSL/TLS termination 및 proxying을 목적으로 합니다. TCP Proxy와 마찬가지로 proxy가 backend로 새 연결을 설정하므로 네트워크 계층에서 원래 클라이언트 source IP를 보존하지 않습니다. TLS offloading에는 유용하지만, VM에서 source IP 기반 rate limiting에는 적합하지 않습니다.

오답입니다. internal TCP Network Load Balancer는 인터넷에 노출되지 않으며, VPC(및 연결된 네트워크) 내의 private RFC1918 트래픽에 대한 load balancing을 제공합니다. 문제에서 서비스가 인터넷에서 공개적으로 접근 가능해야 한다고 명시하므로, internal load balancer는 L4이더라도 접근성 요구사항을 충족할 수 없습니다.

문제 분석

핵심 개념: 이 문제는 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
문제 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?

Coldline Storage는 분기당 최대 1회 접근되는 데이터에 최적화되어 있어 분기별 컴플라이언스 감사와 정렬됩니다. Nearline/Standard보다 저장 비용이 낮고, retrieval 요금은 더 높지만 소량의 subset만 드물게 읽는 경우에는 수용 가능합니다. 24개월 보존은 Coldline의 90일 minimum storage duration을 초과하므로 early deletion penalties는 우려 사항이 아니며, 총비용을 최소화합니다.

Nearline Storage는 월 1회보다 덜 접근되는 데이터를 대상으로 합니다. infrequent access를 지원하지만, 일반적으로 Coldline보다 저장 비용이 더 비쌉니다. 제시된 접근 패턴(분기별)과 긴 보존 기간(24개월)을 고려하면, Nearline은 읽기가 월간에 더 가깝거나 operational 제약으로 더 낮은 retrieval 비용이 필요하지 않는 한, 의미 있는 이점 없이 총 저장 비용이 더 높아지는 경우가 많습니다.

Regional Storage는 단일 region의 Standard storage를 의미하며(infrequent-access class가 아님), 해당 region에서 낮은 latency로 자주 접근되는 데이터를 위해 설계되었습니다. 24개월 보존에 간헐적 읽기만 있는 경우, Regional/Standard storage는 데이터가 거의 접근되지 않는데도 더 높은 GB당 저장 단가를 지불하게 되어 Coldline 대비 불필요하게 비쌉니다.

Multi-Regional Storage는 여러 region에 복제되는 Standard storage입니다(legacy 개념이며, 일반적으로 multi-region/dual-region location 선택으로 대체됨). 전 세계적으로 접근되는 active content를 위한 높은 availability와 낮은 latency를 목표로 합니다. 장기 보존과 분기별 읽기에서는 더 높은 저장 비용 때문에 제시된 선택지 중 가장 비싼 옵션이며, premium을 정당화할 만큼 retrieval 요금을 충분히 낮추지도 못합니다.

문제 분석

핵심 개념: 이 문제는 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
문제 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?

오답. public internet egress를 사용하며 storage.googleapis.com에 대한 public IP를 resolve하고 allowlist하는 것에 의존하는데, 이는 변경될 수 있고 정적인 firewall rule 용도로 의도되지 않았습니다. 제약을 위반합니다: outbound internet access 금지, 하드코딩된 public IP 의존 금지, 그리고 Google API 트래픽이 Google이 제어하는 범위로 제한된 프라이빗 경로에 머물러야 한다는 요구사항.

오답. Google Cloud의 proxy VM은 자동으로 Google APIs로의 트래픽을 프라이빗하게 만들지 않습니다; proxy는 여전히 Cloud Storage endpoint에 도달할 경로가 필요합니다. 추가 구성 없이는 일반적으로 public internet/NAT 또는 external IP를 사용하게 되며, 이는 허용되지 않습니다. 또한 운영 오버헤드를 추가하고 병목/장애 도메인이 되며, Restricted Google APIs 대비 권장 패턴이 아닙니다.

오답. Compute Engine로 서버를 마이그레이션하는 것은 불필요하며 온프레미스 접근이라는 핵심 요구사항을 해결하지 못합니다. internal load balancer는 이런 방식으로 storage.googleapis.com를 backend로 사용할 수 없습니다; Cloud Storage는 internal TCP/HTTP(S) load balancer에 attach할 수 있는 backend service가 아닙니다. 이 옵션은 load balancing과 Cloud Storage 접근 패턴에 대한 오해를 반영합니다.

정답입니다. 이는 public internet을 사용하지 않고 온프레미스 환경에서 Cloud Storage를 포함한 지원되는 Google APIs에 비공개로 액세스하기 위한 표준 하이브리드 설계입니다. Restricted Google APIs VIP 범위 199.36.153.4/30이 Cloud VPN 또는 Interconnect를 통해 도달 가능하도록 하고, 필요한 API hostname이 restricted.googleapis.com을 통해 해석되도록 DNS를 사용하면, 서버는 Google이 제어하는 주소로만 private connectivity를 통해 트래픽을 전송합니다. 이는 public NAT 없음, 서버에 public IP 없음, 변경될 수 있는 public service IP에 대한 의존 없음이라는 보안 요구 사항을 충족합니다. Cloud Router는 경로를 동적으로 교환하고 VPN에서 Dedicated Interconnect로의 전환을 깔끔하게 지원하므로 적절합니다.

문제 분석

핵심 개념: 이 문제는 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
문제 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?

개별 dashboards의 charts를 공유하는 것은 중앙집중식의 지속적인 관측 가능성을 위한 의도된 메커니즘이 아닙니다. 단편화된 경험을 만들 수 있고, 일반적으로 프로젝트별 dashboards와 유지보수에 의존합니다. 또한 한 곳에서 프로젝트별로 필터링/그룹화하는 것과 같은 진정한 통합 metrics 탐색 계층을 제공하지 않습니다. 겉보기에는 “single pane of glass”처럼 보일 수 있지만, 표준적이고 확장 가능한 Cloud Monitoring 접근은 아닙니다.

세 프로젝트 모두에 Monitoring Viewer를 부여하는 것은 접근 제어 측면에서 필요하지만, 그것만으로는 “single pane of glass” 요구사항을 해결하지 못합니다. 집계된 metrics scope가 없기 때문에 SRE는 Cloud Console에서 프로젝트 컨텍스트를 전환해야 하거나(또는 프로젝트별로 별도 쿼리를 실행해야) 합니다. IAM은 “누가 볼 수 있는가”를 답할 뿐, “통합 뷰가 어디에 존재하는가”를 해결하지 않습니다.

기본 dashboards를 순차적으로 사용하는 방식은 프로젝트별로 컨텍스트 전환이 필요하므로 명시적으로 허용되지 않습니다. 또한 cross-project charts, 집계된 alerting, 통합 metrics explorer 경험을 제공하지 않습니다. 빠르긴 하지만 north-1, south-1, west-1 전반에서 single pane of glass라는 핵심 요구사항을 충족하지 못합니다.

north-1에 Cloud Monitoring workspace(metrics scope)를 만들고 south-1과 west-1을 추가하는 것이 프로젝트 전반의 모니터링을 중앙집중화하는 올바른 내장 방식입니다. scoping project에서 통합된 Metrics Explorer와 dashboards를 제공하면서, 모든 monitored projects에서 metrics를 가져옵니다. 적절한 IAM(예: 각 프로젝트의 Monitoring Viewer)과 결합하면, 커스텀 도구 없이도 요구사항을 빠르고 깔끔하게 충족합니다.

문제 분석

핵심 개념: 이 문제는 여러 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
문제 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?

오답입니다. 문제에서 billing model을 변경할 수 없다고 명시하고 있으며, slot commitment/capacity pricing을 준비하는 것은 billing model 변경입니다. 또한 slot commitment는 일반적으로 관리 오버헤드와 최소 약정 고려사항 없이 단발성 쿼리를 위해 “임시”로 사용하는 형태가 아닙니다. 가능하더라도 on-demand 쿼리 비용을 추정하는 데 요구되는 방법이 아닙니다.

정답입니다. bq CLI로 BigQuery dry run을 수행하면 총 처리 바이트 수(totalBytesProcessed)의 추정치를 반환합니다. on-demand BigQuery 쿼리 과금은 처리 바이트 수를 기준으로 하므로, 이 추정치를 TB로 변환하고 on-demand $/TB 요율을 적용(또는 Pricing Calculator 사용)하면 쿼리를 실행하지 않고도 필요한 사전 비용 추정을 제공할 수 있습니다.

오답입니다. BigQuery on-demand analysis 요금은 클라이언트로 반환되는 바이트 수가 아니라 쿼리가 처리한 바이트 수를 기준으로 합니다. 5천만 행을 반환하는 것은 실무적으로(시간, 클라이언트 메모리, export 비용) 영향을 줄 수 있지만, 처리 바이트 수처럼 on-demand 쿼리 과금을 좌우하지는 않습니다.

오답입니다. 행 수는 처리 바이트 수와 직접적으로 매핑되지 않습니다. BigQuery는 읽기/처리된 바이트 수로 과금하며, 이는 컬럼 크기, 선택한 컬럼, partition pruning, clustering, 쿼리 실행 계획에 따라 달라집니다. 또한 SELECT COUNT(*) 자체가 대량 데이터를 스캔하여 비용이 발생할 수 있어, 안전한 사전 추정이라는 목적에 어긋납니다.

문제 분석

핵심 개념: 이 문제는 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
문제 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?

Node auto-provisioning은 기존 node가 충족할 수 없는 resource를 pending pod가 요청할 때, GPU를 포함하여 새로운 node pool을 자동으로 생성할 수 있으므로 가장 적합합니다. 즉, 렌더링 작업이 queue에 없을 때는 cluster에 비용이 많이 드는 GPU node가 전혀 없을 수 있으며, 이는 작업이 한 달에 2~3일만 들어온다는 점에서 중요합니다. 이러한 auto-provisioned node에 standard non-preemptible VM을 사용하면, 10~16시간 동안 실행되고 checkpoint가 불가능한 작업이 중단되어서는 안 된다는 요구 사항을 충족할 수 있습니다. 이 옵션은 automatic scaling과 가장 낮은 idle 인프라 비용 사이의 균형을 가장 잘 맞춥니다.

Vertical Pod Autoscaler는 pod의 CPU 및 memory request만 조정할 뿐, GPU를 지원하는 node를 생성하거나 specialized accelerator를 위한 cluster 인프라를 관리하지 않습니다. 또한 업데이트된 권장 사항을 적용하기 위해 pod를 evict하고 다시 생성할 수 있는데, 이는 checkpoint에서 재개할 수 없는 장시간 렌더링 작업에는 위험합니다. VPA가 resource sizing을 개선하더라도, 작업이 도착했을 때 NVIDIA GPU capacity가 확보된다는 보장은 없습니다. 따라서 이 시나리오의 핵심인 scheduling 및 비용 문제를 해결하지 못합니다.

Preemptible VM은 렌더링이 완료되기 전에 Google Cloud에 의해 종료될 수 있으므로, 재시작 불가능한 작업에는 명백히 잘못된 선택입니다. checkpointing이 없는 10~16시간 렌더링 작업은 node가 회수되면 모든 진행 상황을 잃게 됩니다. 이 옵션은 비용을 줄여주기는 하지만, 작업이 중단되어서는 안 된다는 요구 사항을 위반합니다. 이러한 워크로드에서는 비용 절감이 완료 보장보다 우선될 수 없습니다.

autoscaling이 있는 전용 GPU node pool은 사용 가능하지만, 최소 크기를 1로 설정하면 한 달 대부분 동안 작업이 없더라도 최소 하나의 GPU node가 계속 실행됩니다. 이는 매달 며칠만 나타나는 워크로드의 비용을 최소화해야 한다는 요구 사항과 직접적으로 충돌합니다. 또한 기준값 1에서 시작하는 autoscaling은 pending 작업이 있을 때만 GPU node를 프로비저닝하는 방식보다 절감 효과가 적습니다. 더 비용 효율적인 automatic scaling 옵션이 존재하므로, 이것은 최선의 정답이 아닙니다.

문제 분석

핵심 개념: 이 문제는 드물게 발생하고 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
문제 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?

정답입니다. gcloud config set container/cluster staging-ops는 활성 Cloud SDK 구성에 영구 기본값을 설정합니다. 적절한 프로젝트와 존/위치도 설정한 후에는, gcloud가 구성에서 이를 읽기 때문에 gcloud container 명령에서 클러스터 이름을 생략할 수 있습니다. 이는 CLI 기본값을 설정하는 표준적이고 지원되는 방식이며, ACE 시험에서 자주 출제됩니다.

오답입니다. gcloud container clusters update staging-ops는 클러스터 리소스 자체(예: 노드 풀 설정, 애드온, release channel, maintenance windows)를 수정하는 것이지, 로컬 CLI 기본값을 수정하는 것이 아닙니다. 이는 향후 명령이 기본적으로 어떤 클러스터를 대상으로 하는지 변경하지 않습니다. “update”라는 단어가 포함되어 있어 그럴듯해 보일 수 있지만, 이는 클러스터 구성을 업데이트하는 것이지 gcloud 환경을 업데이트하는 것이 아닙니다.

오답입니다. Cloud SDK는 기본 클러스터 대상을 설정하기 위해 ~/.gcloud/gke.default 같은 사용자가 만든 파일을 사용하지 않습니다. gcloud는 gcloud config를 통해 관리되는 구성 디렉터리/파일에 구성 속성을 저장하며, gcloud가 읽을 것이라고 기대하면서 임의의 사용자 정의 파일을 만들면 안 됩니다. 이는 기본값을 dotfile로 설정하는 다른 도구에서 비롯된 흔한 오해를 반영합니다.

오답입니다. gcloud 기본값을 설정하기 위한 지원되는 ~/.gcloud/defaults.json 메커니즘은 없습니다. gcloud가 내부 구성 상태를 유지하긴 하지만, 이는 수동으로 JSON 파일을 만드는 방식이 아니라 gcloud config set 및 명명된 configurations를 통해 관리됩니다. 시험에서 gcloud 기본값을 위해 임의의 파일을 만들라는 답은 일반적으로 위험 신호입니다.

문제 분석

핵심 개념: 이 문제는 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를 떠올리세요. - 여러 프로젝트/리전에 동일한 이름의 클러스터가 있을 때 모호함을 피하기 위해 프로젝트와 위치 기본값이 설정되어 있는지 항상 확인하세요.

합격 후기(11)

E
e******Nov 25, 2025

학습 기간: 1 month

I could count probably like 15+ question exactly the same on the real exam. Cloud pass always the best pratical exam questions.

W
w******Nov 24, 2025

학습 기간: 1 month

Thank you for the excellent source for preparing for cert exams, detail explanation really helped. Passed the exam.

J
J****Nov 13, 2025

학습 기간: 1 month

Got my cert after going though the practice questions. I have a background in GCP so it was a bit easy to grasp for me.

J
J***Nov 13, 2025

학습 기간: 1 month

This helped my pass the ACE on 1/12 , highly recommended.

B
b******Nov 10, 2025

학습 기간: 1 month

Passed the exam in first attempt!

다른 모의고사

Practice Test #2

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

지금 학습 시작하기

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