Google Cloud Digital Leader

Practice Test #2

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

50문제90분700/1000합격 점수

기출 문제 보기

AI 기반

3중 AI 검증 답안 및 해설

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

GPT Pro

Claude Opus

Gemini Pro

선택지별 상세 해설

심층 문제 분석

3개 모델 합의 정확도

기출 문제

문제 1

A smart home company runs its control platform on a managed messaging service from its cloud provider that guarantees 99.99% monthly availability, but last month monitoring showed only 99.6% availability (about 173 minutes of cumulative downtime), intermittently preventing devices from receiving commands—what is a likely impact on the organization?

문제 2

A regional hospital network plans to use Google Cloud’s advanced ML services (such as Vertex AI) for radiology model training and inference, but regulations require all 120 TB of patient images and metadata to remain stored only in its on-premises data center; the hospital has a 5 Gbps Dedicated Interconnect to Google Cloud and must ensure no PHI is persisted in the public cloud. Which overall cloud strategy should they adopt to meet these constraints while still using Google Cloud’s ML capabilities?

문제 분석

핵심 개념: 이 문제는 클라우드 배포 모델(하이브리드 vs. 퍼블릭/프라이빗/멀티 클라우드)과, Google Cloud의 관리형 ML 서비스(예: Vertex AI)를 사용하면서도 엄격한 데이터 상주성 및 보안 요구사항(퍼블릭 클라우드에 PHI를 저장하지 않음)을 충족하는 방법을 평가합니다. 정답인 이유: 하이브리드 클라우드 접근 방식은 온프레미스 인프라(규제 대상 PHI가 반드시 남아 있어야 하는 위치)와 퍼블릭 클라우드 서비스(탄력적 컴퓨팅 및 관리형 ML 기능)를 결합합니다. 병원은 120 TB의 이미지/메타데이터를 온프레미스에만 저장한 채, 5 Gbps Dedicated Interconnect를 사용해 Google Cloud로 프라이빗하고 고처리량의 연결을 구성할 수 있습니다. 이는 스토리지가 온프레미스에 유지되므로 “퍼블릭 클라우드에 PHI가 저장되면 안 됨” 제약과 부합하며, 아키텍처 및 거버넌스에 따라 통제된 일시적 처리만 Google Cloud에서 수행할 수 있습니다. 주요 기능 / 구현 방법: - 연결: Dedicated Interconnect는 인터넷 VPN 대비 프라이빗 연결과 예측 가능한 대역폭/지연 시간을 제공하여 대규모 데이터 접근 패턴을 지원합니다. - 데이터 거버넌스: PHI가 Cloud Storage/BigQuery 등에 기록되지 않도록 설계합니다. 엄격한 IAM, VPC Service Controls(해당되는 경우), 조직 정책을 사용해 우발적 데이터 유출을 줄입니다. - 처리 패턴: 학습/추론 중 온프레미스에서 데이터를 스트리밍하거나 접근하고, 임시 컴퓨트 디스크 및 로그에 PHI가 남지 않도록 보장합니다. 가능하다면 온프레미스에서 비식별화/토큰화를 고려하고, 비-PHI 특징(feature)만 클라우드로 전송합니다. - Architecture Framework 정렬: 이는 주로 Trust and Security 결정(데이터 상주성, 컴플라이언스, 최소 권한)이지만, 신뢰성과 성능(전용 프라이빗 연결)도 함께 다룹니다. 흔한 오해: - “Private cloud”는 데이터가 온프레미스에 남는다는 점에서 그럴듯해 보이지만, Google Cloud의 관리형 ML 서비스를 사용해야 한다는 요구사항을 충족하지 못합니다. - “Public cloud”는 PHI를 Google 관리 스토리지/서비스에 저장/처리하는 것을 의미하므로 부적절합니다. - “Multi-cloud”는 여러 퍼블릭 클라우드를 사용하는 것이며, 온프레미스에만 저장해야 한다는 요구사항을 해결하지 못합니다. 시험 팁: 문제에서 데이터가 온프레미스에 남아야 한다(규제/주권/PHI)고 하면서도 퍼블릭 클라우드 서비스를 사용하길 원한다면, 기본 정답은 하이브리드 클라우드입니다. Dedicated Interconnect, on-prem data center, “no data persisted in cloud” 같은 키워드는 하이브리드 연결과 엄격한 데이터 거버넌스 통제를 강하게 시사합니다.

문제 3

An e-commerce startup named ParcelPeak operates a Cloud SQL for PostgreSQL instance (db-custom-4-15360) ingesting about 400,000 order, payment, and refund rows per day from 7 microservices across 3 regions. Executives request weekly KPI dashboards and ad-hoc cohort revenue analysis without exporting data to on-prem systems. In this situation, which capability of Cloud SQL most directly helps the team turn this operational data into business insights?

문제 분석

핵심 개념: 이 문제는 Cloud SQL의 역할을 관리형 relational database로 인식하고, 조직이 그 안에 저장된 운영 데이터를 통해 일반적으로 어떻게 비즈니스 인사이트를 도출하는지에 관한 것입니다. Cloud SQL 자체는 business intelligence 플랫폼이 아니지만, 표준 database connectivity를 사용해 analytics 및 reporting 도구와 연결할 수 있습니다. 팀에 가장 직접적으로 도움이 되는 기능은 BI 도구 및 analytics 플랫폼과의 통합으로, 이를 통해 cloud-hosted relational data에서 dashboard를 구축하고 분석을 실행할 수 있습니다. 정답인 이유: 경영진은 데이터를 다시 on-premises로 옮기지 않고 KPI dashboard와 ad-hoc revenue analysis를 원합니다. Cloud SQL for PostgreSQL은 표준 PostgreSQL-compatible connection을 지원하므로 Looker Studio, Looker 및 기타 analytics 플랫폼이 데이터를 query하고 인사이트를 제공할 수 있습니다. 따라서 A 옵션이 가장 적합합니다. 이는 Cloud SQL이 비즈니스 인사이트에 기여하는 실질적인 방식을 설명하기 때문입니다. 즉, reporting 및 analysis를 위한 관리형 relational source 역할을 합니다. 주요 기능: Cloud SQL은 표준 SQL access, secure connectivity, backup, high availability option을 갖춘 관리형 PostgreSQL을 제공합니다. 익숙한 relational interface를 사용하기 때문에 많은 BI 및 reporting 도구가 직접 연결할 수 있습니다. 이로 인해 운영 reporting을 위한 source of truth로 유용하지만, 더 무거운 analytical workload는 전용 analytics service가 더 적합한 경우가 많습니다. 일반적인 오해: 흔한 실수는 Cloud SQL에 built-in dashboarding, machine learning 또는 ETL 기능이 포함되어 있다고 가정하는 것입니다. Cloud SQL은 기본적으로 chart를 생성하거나, model을 학습시키거나, unstructured data를 structured dataset으로 변환하지 않습니다. 이러한 기능은 Cloud SQL에 연결되는 다른 Google Cloud 또는 partner service에서 제공합니다. 시험 팁: Digital Leader 문제에서는 각 product를 그 주요 목적에 맞게 매핑하세요. Cloud SQL은 관리형 relational database 및 transactional workload용이고, Looker 및 Looker Studio와 같은 BI 도구는 dashboard와 analysis에 사용됩니다. 문제가 Cloud SQL이 인사이트 생성에 어떻게 도움이 되는지 묻는다면, 가장 좋은 답은 보통 native analytics 기능보다는 analytics 도구와의 통합에 관한 것입니다.

문제 4

An online language-learning platform with 500,000 paying learners sees a 15% annual cancellation rate and wants to proactively retain users by offering a 20% discount and personalized study plans. They have 36 months of historical data including demographics, session frequency, lesson completion rates, support tickets, and a label indicating whether each user canceled. What should the company do to use data and AI to identify at-risk subscribers for targeted retention?

문제 5

A media-streaming company operates 14 microservices on Google Kubernetes Engine (GKE), receives about 70 paging alerts per week, and estimates that roughly 40% of engineering hours are spent on repetitive, manual tasks like log triage, ticket updates, and release rollbacks; the team wants to boost operational efficiency without reducing service scope or relaxing SLOs. Which SRE best practice should they prioritize to increase efficiency?

문제 분석

핵심 개념: 이 문제는 SRE의 “toil” 개념과 자동화를 통해 이를 줄이는 모범 사례를 평가합니다. SRE에서 toil은 반복적이고 수동적이며 자동화 가능하지만 지속적인 가치를 제공하지 않는 작업(예: 로그 트리아지, 티켓 업데이트, 수동 롤백)입니다. 높은 페이징 볼륨(주 70회)과 엔지니어링 시간의 40%가 반복 작업에 쓰인다는 것은 과도한 운영 부담과 자동화 부족을 시사합니다. 정답이 맞는 이유: 선택지 D는 서비스 범위를 줄이거나 SLO를 완화하지 않으면서, 제시된 문제인 운영 비효율을 직접적으로 해결합니다. SRE 모범 사례는 toil을 체계적으로 식별하고 우선순위를 정한 뒤, runbook, CI/CD, 셀프서비스 워크플로, 자동 복구(auto-remediation)로 자동화하는 것입니다. 이는 신뢰성과 효율성을 동시에 높입니다. 수동 단계가 줄어들면 인적 오류가 감소하고, 인시던트 대응이 빨라지며, 엔지니어가 “서비스를 겨우 유지하는” 일 대신 시스템 개선(용량, 복원력, 관측 가능성)에 집중할 수 있습니다. 주요 기능 / 실천 방법 (Google Cloud 맥락): GKE 마이크로서비스에서 흔한 자동화 패턴은 다음을 포함합니다: 표준화된 runbook과 인시던트 playbook; 점진적 배포와 자동 롤백을 갖춘 CI/CD 파이프라인(Cloud Build, Artifact Registry, Cloud Deploy); GitOps(Config Sync/Anthos Config Management)와 정책 가드레일을 통한 셀프서비스 운영; Cloud Monitoring 알림 + Cloud Functions/Cloud Run 리스폰더를 활용한 auto-remediation; 그리고 Cloud Logging, Error Reporting, Cloud Trace를 통한 로그/트레이스 상관관계 개선으로 트리아지 시간 단축. 또한 SRE는 error budget을 강조합니다. SLO가 위험해지면 신뢰성 작업과 toil 감소를 우선순위로 둡니다. 흔한 오해: 일부는 대시보드를 줄이면(A) 의사결정이 빨라진다고 생각하지만, 이는 관측 가능성을 약화시키고 위험을 증가시킵니다. 또 다른 일부는 “개발자가 프로덕션을 소유한다”(B)를 DevOps 성숙도로 해석할 수 있으나, SRE를 온콜에서 제외한다고 해서 toil이 사라지지 않으며 인시던트 처리만 악화될 수 있습니다. 장애 영향 측정(C)은 “서류 작업”처럼 느껴질 수 있지만, 학습, 우선순위 결정, SLO 거버넌스에 필수적입니다. 시험 팁: 알림(페이징) 볼륨이 높고 반복적인 수동 작업에 많은 시간이 쓰인다면 이를 “toil”로 매핑하고, 주요 레버로 자동화를 선택하세요. Digital Leader 문제는 종종 SRE 원칙과의 정렬을 기대합니다: 강한 관측 가능성, 비난 없는 학습(blameless learning), error budget, 그리고 신뢰성과 운영 효율을 모두 개선하는 자동화입니다.

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

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

문제 6

Your healthcare analytics startup operates 18 Google Cloud projects across 3 folders under a single organization, and auditors require quarterly organization-wide compliance reports aligned to CIS benchmarks and PCI DSS; you need a native service that continuously identifies misconfigurations and threats across all current and future projects and provides centralized dashboards to help maintain and attest to compliance. Which Google Cloud product should you use?

문제 분석

핵심 개념: 이 문제는 Google Cloud에서 조직 전체 보안 상태 관리와 컴플라이언스 보고를 테스트합니다. 핵심 아이디어는 전체 조직(향후 프로젝트 포함) 전반에서 자산을 지속적으로 발견하고, 잘못된 구성/위협을 탐지하며, 컴플라이언스 증적과 보고를 지원하는 네이티브 중앙집중형 서비스를 사용하는 것입니다. 정답이 맞는 이유: Security Command Center (SCC)는 Google Cloud의 통합 보안 및 리스크 관리 플랫폼입니다. 조직 수준에서 활성화하여 적절히 구성하면 새로 생성되는 프로젝트를 포함해 모든 폴더와 프로젝트 전반에 대한 중앙집중형 가시성을 제공할 수 있습니다. SCC는 여러 소스(예: Security Health Analytics, Event Threat Detection, 티어에 따라 Vulnerability/Container findings 등)의 findings를 집계하고, CIS 같은 공통 벤치마크 및 PCI DSS와 관련된 요구사항에 대한 컴플라이언스 평가를 팀과 감사인이 수행할 수 있도록 대시보드와 보고서로 제공합니다. 주요 기능 / 사용 방법: SCC는 조직 수준 활성화와 중앙집중형 관리를 지원하여 Google Cloud Architecture Framework의 “Security, privacy, and compliance” pillar(중앙 거버넌스, 지속적 모니터링, 감사 가능성)와 정렬됩니다. Security Health Analytics에는 CIS Google Cloud Foundations Benchmark 및 기타 모범 사례 컨트롤에 매핑된 기본 제공 detector가 포함되어 있으며, 과도하게 허용적인 IAM, public bucket, 안전하지 않은 firewall rule 같은 잘못된 구성을 플래그합니다. Findings는 organization/folder/project 기준으로 필터링할 수 있고, BigQuery 또는 SIEM 도구로 export하여 분기별 컴플라이언스 증적을 생성하는 데 사용할 수 있습니다. 또한 SCC는 시점성 점검이 아니라 지속적 모니터링을 지원하는데, 이는 “현재 및 향후 프로젝트”에 매우 중요합니다. 흔한 오해: Cloud Logging은 감사 추적에 필수적이지만, 벤치마크에 정렬된 상태 관리나 컴플라이언스 대시보드를 네이티브로 제공하지는 않습니다. IAM은 접근을 위한 control plane이지, 지속적인 컴플라이언스 보고 제품이 아닙니다. Cloud Armor는 웹 공격(WAF/DDoS)으로부터 보호하지만, 모든 서비스에 걸친 조직 전체 컴플라이언스 상태를 제공하지는 않습니다. 시험 팁: “organization-wide”, “continuous identification of misconfigurations”, “threat detection”, “centralized dashboards/compliance”가 보이면 Security Command Center를 떠올리세요. 감사 증적을 위해서는 SCC findings export(BigQuery)와 CIS 스타일 컨트롤에 매핑되는 기본 제공 detector(Security Health Analytics)를 기억하세요. 또한 범위에 주목하세요: 조직 수준에서 활성화한다는 점이 멀티 프로젝트 거버넌스의 결정적 힌트입니다.

문제 7

Your team is building an IoT telemetry platform for a fleet of 15,000 sensors across 120 factories; each sensor sends JSON payloads every 10 seconds, and the fields differ by device model and firmware version, with new attributes added weekly; to avoid frequent schema migrations and keep write latency under 50 ms, you are considering a non-relational database. In this scenario, what is a defining feature of the non-relational database that makes it a good fit?

문제 분석

핵심 개념: 이 문제는 페이로드가 진화하는 고수집(ingest) IoT 텔레메트리에 대해 비관계형(NoSQL) 데이터베이스가 흔히 선택되는 이유를 테스트합니다. Google Cloud에서 대표적인 NoSQL 옵션으로는 Firestore(document), Bigtable(wide-column) 등이 있으며, 공통적으로 전통적인 관계형 데이터베이스에 비해 스키마 유연성이 크다는 점이 핵심입니다. 정답이 맞는 이유: 15,000개의 센서가 10초마다 JSON을 전송하므로 쓰기 볼륨이 높고, 디바이스 모델/firmware에 따라 속성 집합이 빠르게 변하며 매주 새로운 필드가 추가됩니다. 많은 비관계형 데이터베이스(특히 document 데이터베이스)의 결정적 특징은 유연한 데이터 모델로, 각 레코드/문서가 스키마 마이그레이션 없이도 서로 다른 필드를 가질 수 있다는 점입니다. 이는 50 ms 미만의 낮은 쓰기 지연 시간을 유지하면서도 빈번한 스키마 변경을 피해야 한다는 요구사항을 직접적으로 충족합니다. 왜냐하면 쓰기가 엄격한 테이블 스키마에 대한 검증을 필요로 하거나 DDL 마이그레이션을 유발하지 않기 때문입니다. 핵심 기능 / 모범 사례: NoSQL 시스템은 종종 반정형 데이터(예: JSON documents)를 지원하고 “sparse” 레코드(필드가 없어도 괜찮음)를 허용합니다. 이는 Google Cloud Architecture Framework의 변경과 확장성을 고려한 설계 가이드와도 부합합니다. 즉, 데이터 수집을 경직된 스키마 진화로부터 분리하고, 액세스 패턴(고처리량 쓰기, 단순한 키 기반 읽기)에 맞는 스토리지를 선택하는 것입니다. 실무에서는 수집(대개 Pub/Sub)과 쓰기 처리량 및 예측 가능한 지연 시간에 최적화된 NoSQL 스토어를 함께 사용하고, 비용 관리를 위해 데이터 라이프사이클 제어(TTL/retention)도 적용합니다. 흔한 오해: 사람들은 종종 “데이터베이스의 강력함”을 SQL 스타일의 joins와 복잡한 리포팅과 연관 짓습니다. 하지만 joins와 통합 리포팅은 일반적으로 관계형 데이터베이스나 분석용 웨어하우스(예: BigQuery)의 강점이지, NoSQL 운영 스토어의 정의적 특징은 아닙니다. NoSQL은 일부 관계형 기능을 대가로 수평 확장성, 유연한 스키마, 예측 가능한 성능을 얻습니다. 시험 팁: “JSON”, “레코드마다 필드가 다름”, “새 속성이 자주 추가됨”, “스키마 마이그레이션 회피”가 보이면 document/NoSQL 유연성을 떠올리세요. “joins”, “고정 스키마”, “복잡한 다중 테이블 쿼리”가 보이면 관계형/SQL을 떠올리세요. 또한 운영 텔레메트리 스토리지는 종종 분석과 분리됩니다. 먼저 원시 이벤트를 유연하게 저장한 뒤, 나중에 리포팅을 위해 변환합니다.

문제 8

A sports-streaming startup plans to launch a new containerized live-score microservice on Google Cloud; traffic could fluctuate from 30 requests per minute during off-hours to 15,000 requests per minute during championship games, and they want to avoid paying for idle capacity when demand drops to near zero overnight. Which benefit of a serverless platform best addresses this requirement?

문제 분석

핵심 개념: 이 문제는 사용량 기반 과금과 결합된 자동 확장이라는 serverless의 핵심 이점을 테스트합니다. Google Cloud에서 Cloud Run과 같은 containerized applications용 serverless 플랫폼은 트래픽이 급증할 때 빠르게 scale out하고, 트래픽이 감소할 때는 많은 경우 zero까지 크게 scale down할 수 있습니다. 이는 유휴 리소스에 비용을 지불하지 않으면서 예측 불가능한 수요를 처리해야 하는 요구 사항과 직접적으로 일치합니다. 정답인 이유: 이 startup은 매우 낮은 요청 볼륨부터 championship 이벤트 동안의 큰 급증까지, 트래픽 변동성이 매우 클 것으로 예상합니다. 이를 가장 잘 해결하는 serverless 이점은 scale-to-zero를 포함한 자동 확장성과 실제 사용한 리소스에 대해서만 비용을 지불하는 방식입니다. 플랫폼이 미리 프로비저닝된 서버를 요구하는 대신 용량을 자동으로 조정하기 때문입니다. 즉, 수요가 거의 zero로 떨어질 때 비용을 최소화하면서도 서비스는 갑작스러운 트래픽 증가를 처리할 수 있습니다. 주요 기능 / 모범 사례: Serverless 플랫폼은 인프라 용량을 수동으로 관리할 필요를 없애 운영 오버헤드를 줄여줍니다. 특히 요청 볼륨 변화에 빠르게 대응할 수 있으므로, 급격히 변하거나 예측 불가능한 워크로드에 매우 적합합니다. Google Cloud의 containerized microservices에서는 Cloud Run이 이 패턴과 연관 지어 생각해야 할 대표적인 예입니다. 흔한 오해: 보안, 복원력, 개발자 생산성과 같은 serverless의 이점을 여기서 테스트하는 주요 이점과 혼동하기 쉽습니다. 물론 이러한 요소들도 managed 플랫폼의 장점일 수 있지만, 트래픽 급증과 유휴 비용 절감이라는 문제를 직접 해결하지는 않습니다. 핵심 단서는 변동하는 수요와 서비스가 사용되지 않을 때 비용을 지불하고 싶지 않다는 요구의 조합입니다. 시험 팁: 문제에서 예측 불가능한 트래픽, 갑작스러운 급증, 유휴 인프라 비용 회피가 언급되면 serverless autoscaling과 사용량 기반 과금을 떠올리세요. 워크로드가 Google Cloud에서 containerized되어 있다면, 가장 가능성이 높은 서비스 연관성은 Cloud Run입니다. 먼저 비즈니스 요구 사항, 즉 탄력성과 비용 효율성에 집중하세요.

문제 9

A nationwide food delivery platform operates workloads across 3 Google Cloud projects and needs a fully managed, centralized dashboard to view infrastructure metrics, create alerts, and run built-in 1-minute HTTP uptime checks for two public APIs; which Google Cloud service should they use?

문제 분석

핵심 개념: 이 문제는 Google Cloud Operations Suite에 대한 지식을 평가하며, 특히 여러 Google Cloud 프로젝트 전반에서 metrics, dashboards, alerting, uptime monitoring에 대한 중앙 집중식 observability를 제공하는 서비스가 무엇인지 묻습니다. 정답인 이유: Cloud Monitoring은 infrastructure 및 service metrics를 수집하고 시각화하며, 중앙 집중식 dashboards를 구축하고, alerting policies를 구성하는 데 사용되는 완전관리형 Google Cloud 서비스입니다. 또한 public endpoints를 위한 Uptime Checks를 포함하므로, 시나리오에 언급된 두 개의 public API 가용성을 모니터링하기 위한 기본 서비스입니다. 3개의 Google Cloud 프로젝트에 걸쳐 분산된 workloads의 경우, Cloud Monitoring은 metrics scopes를 통해 중앙 집중식 가시성을 지원하므로 운영자가 하나의 scoping project에서 여러 프로젝트를 모니터링할 수 있습니다. 주요 기능 / 구성 / 모범 사례: - Metrics scopes를 사용하면 여러 프로젝트의 metrics를 하나의 중앙 집중식 Monitoring view로 집계할 수 있습니다. - Dashboards는 Compute Engine, GKE, Cloud Run, load balancers 및 기타 Google Cloud resources에 대한 기본 제공 및 custom charts를 표시할 수 있습니다. - Alerting policies는 metric thresholds, uptime checks 및 기타 Monitoring signals를 기반으로 생성할 수 있습니다. - Uptime Checks는 Cloud Monitoring에 기본 포함되어 있으며, public HTTP/HTTPS endpoints의 가용성을 확인하는 올바른 기본 기능입니다. - Monitoring은 notification channels 및 incident workflows와 통합되므로 중앙 운영 팀에 적합합니다. 일반적인 오해: Cloud Logging은 둘 다 Google Cloud Operations Suite의 일부이기 때문에 Monitoring과 자주 혼동되지만, Logging은 infrastructure dashboards 및 uptime monitoring을 위한 기본 서비스라기보다 log entries를 수집하고 쿼리하는 데 중점을 둡니다. Cloud Trace와 Cloud Profiler는 특화된 application performance 도구이며, 여기서 요구하는 중앙 집중식 infrastructure monitoring 기능을 제공하지 않습니다. 시험 팁: 문제에서 dashboards, infrastructure metrics, alerting, uptime checks가 함께 언급되면 일반적으로 Cloud Monitoring이 정답입니다. 시나리오에서 여러 프로젝트도 언급된다면 metrics scopes와 중앙 집중식 observability를 떠올리세요. 각 서비스를 주요 목적에 맞게 연결하여 Monitoring을 Logging, Trace, Profiler와 구분하세요.

문제 10

A retail analytics startup runs 12 microservices on Cloud Run and GKE across two Google Cloud projects in us-central1 and europe-west1, and they need a single Google-managed service to automatically collect, index, and retain all application logs (stdout/stderr and system logs) from these workloads for troubleshooting and log-based metrics without installing any third-party agents; which service should they use?

문제 분석

핵심 개념: 이 문제는 중앙집중식 로그 수집 및 관리를 위한 Google Cloud의 operations suite를 평가합니다. 정답 서비스는 Cloud Logging(Google Cloud Observability의 일부)이며, Google 관리형 로깅 백엔드로서 Google 관리형 컴퓨팅 서비스에서 로그를 자동으로 수집합니다. 정답인 이유: Cloud Logging은 서드파티 에이전트 없이도 Cloud Run과 GKE의 로그를 자동으로 수집, 인덱싱, 저장합니다. Cloud Run의 경우 요청 로그와 애플리케이션 stdout/stderr가 기본적으로 캡처됩니다. GKE의 경우 시스템 및 워크로드 로그를 Google 관리형 통합(Cloud Logging for GKE)을 통해 Cloud Logging으로 라우팅할 수 있어, 프로젝트와 리전 전반에서 중앙집중식 트러블슈팅이 가능합니다. 또한 Cloud Logging은 로그 기반 메트릭(log-based metrics)을 지원하며, 이는 프롬프트에서 명시적으로 요구하는 사항입니다. 주요 기능 / 구성 / 모범 사례: - 프로젝트/리전 전반의 중앙화: aggregated log views( Log Analytics / Log Explorer의 멀티 프로젝트 스코프) 및/또는 log sinks를 사용해 로그를 중앙 로깅 프로젝트로 라우팅합니다. - 보존 및 컴플라이언스: log bucket 보존 기간(기본값은 log bucket 유형에 따라 다름)을 구성하고 필요 시 CMEK를 사용합니다. 보존 기간은 log bucket별로 설정할 수 있습니다. - 인덱싱 및 쿼리: 로그는 빠른 검색을 위해 인덱싱되며, Log Explorer와 Log Analytics가 구조화된 쿼리를 지원합니다. - 로그 기반 메트릭: 로그 엔트리에서 카운터/분포 메트릭을 생성하여 SLO 및 알림에 활용합니다. - 비용 제어: exclusion filters로 노이즈가 많은 로그를 드롭하고, sinks를 사용해 필요한 로그만 BigQuery/Cloud Storage로 라우팅합니다. 흔한 오해: Cloud Monitoring은 Logging과 같은 operations suite에 포함되어 있어 자주 혼동되지만, Monitoring은 메트릭, 대시보드, 알림에 초점이 있으며 로그 수집/보존이 아닙니다. Cloud Trace와 Profiler는 성능 진단(지연 시간 트레이스 및 CPU/메모리 프로파일링)을 위한 것으로, 중앙집중식 로그 관리가 아닙니다. 시험 팁: “collect, index, retain logs”, “stdout/stderr”, “system logs”, “log-based metrics”, “no agents” 같은 표현이 보이면 Cloud Logging을 떠올리세요. 문제가 메트릭/알림을 강조하면 Cloud Monitoring, 서비스 간 요청 지연 시간을 강조하면 Cloud Trace, 코드 수준의 CPU/메모리 핫스팟을 강조하면 Cloud Profiler를 생각하면 됩니다. 또한 크로스 프로젝트 요구사항은 보통 aggregated views 및/또는 중앙화된 sinks와 log buckets로 해결한다는 점을 기억하세요.

합격 후기(7)

이

이**Nov 17, 2025

학습 기간: 1 month

시험 문제랑 많이 유사해서 좋았어요. 강의 다 듣고난 후에 문제 찾기 어려웠는데 앱 너무 잘 이용했네요

**************Nov 12, 2025

학습 기간: 1 month

Good questions and explanations. The resource is very similar to the real exam questions. Thanks.

S***Nov 10, 2025

학습 기간: 1 month

This is exactly what you need to pass the GCP CDL exam. The look and feel are exactly how you would experience the real exam. The questions are very similar and you'll even find a few on the exam itself. I would recommend this for anyone looking to obtain this certification. The exam is not an easy one, so the explanations to the questions are very helpful to solidify your understanding and help.

a***Nov 4, 2025

학습 기간: 2 months

I used Cloud Pass to prepare for the GCP CDL exam, and it made a huge difference. The practice questions covered a wide range of scenarios I actually saw on the test. The explanations were clear and helped me understand how LookML and data modeling work in real projects. If you focus on understanding the logic behind each question, this app is more than enough to pass.

d********Oct 31, 2025

학습 기간: 1 month

Cloud Pass was my main study tool for the GCP CDL exam, and I passed on the first try. The questions were realistic and helped me get comfortable with Looker concepts, permissions, explores, and model structures. I especially liked that I could reset my progress and re-solve the tricky questions. Strongly recommend this for anyone targeting CDL.