연습 문제

문제 1

A media-streaming company is migrating a 12-node analytics backend to a fully managed relational database service on Google Cloud that prohibits custom agents and targets a 99.95% monthly SLA; to reduce operational toil without writing maintenance scripts, which routine system-maintenance task will the managed platform perform automatically across all instances?

문제 분석

핵심 개념: 이 문제는 Google Cloud에서 완전 관리형 관계형 데이터베이스 서비스(예: Cloud SQL 또는 AlloyDB)가 운영 측면에서 무엇을 대신해 주는지를 테스트합니다. “custom agents를 금지”하고 높은 가용성 SLA(월 99.95%)를 제시하는 것은 Google이 기반 인프라와 데이터베이스 유지보수의 상당 부분을 운영하는 관리형 플랫폼을 가리킵니다. 정답이 맞는 이유: 관리형 데이터베이스 플랫폼은 DBA와 스크립트가 필요했을 반복적이고 정형화된 유지보수 작업을 대신 수행하여 운영 부담을 줄입니다. 대표적인 예가 patch management로, 데이터베이스 엔진에 security patches를 적용하고 minor-version upgrades를 수행하는 것입니다. Cloud SQL에서는 maintenance updates(보안 패치 포함)를 Google이 처리하며, 유지보수 시점을 통제하기 위해 maintenance window로 일정을 잡을 수 있습니다. 이는 “maintenance scripts를 작성하지 않고” “모든 instances에 걸쳐”라는 표현과 직접적으로 부합하며, 플랫폼이 fleet-wide로 업데이트를 조율하기 때문입니다. 주요 기능 / Best Practices: - Automated maintenance: Google이 patches와 minor updates를 적용하며, 일반적으로 중단을 최소화하기 위해 maintenance window를 선택합니다. - High availability: 99.95% SLA는 보통 HA 구성(regional/replica-based)과 연관되며, 이는 downtime을 줄이도록 maintenance가 배포되는 방식에도 영향을 줍니다. - Shared responsibility: 사용자는 schema, queries, access controls는 여전히 관리하지만, Google은 기반 OS, storage, 그리고 많은 engine maintenance 작업을 관리합니다. - Architecture Framework 정렬: 이는 Operational Excellence(자동화, toil 감소)와 Security(적시 patching)를 지원합니다. 흔한 오해: 사람들은 “fully managed”가 Google이 IAM 설계, data lifecycle/archival policies, 또는 프로젝트 전반의 cost optimization까지 관리한다고 종종 가정합니다. 실제로는 shared responsibility 모델에서 IAM roles/policies와 data retention 전략은 고객 책임이며, cost optimization도 데이터베이스 서비스가 프로젝트 전반에 걸쳐 자동으로 수행하지 않습니다. Exam Tips: Digital Leader 문제에서 “fully managed database”를 보면 automated backups(구성 가능), patching/minor upgrades, replication/HA 옵션, 그리고 단순화된 운영을 떠올리세요. cross-project spend optimization이나 비즈니스별 data lifecycle 규칙을 설명하는 선택지는 보통 관리형 데이터베이스의 자동 기능이 아닙니다.

문제 2

A logistics company operates 24 Kubernetes clusters (12 on-premises, 8 on Google Cloud, and 4 on AWS) to support microservices across 60 warehouses and needs a single, centralized platform to consistently manage policies, configurations, service mesh, and observability across all environments without relocating workloads; which Google Cloud service should they choose?

문제 분석

핵심 개념: 이 문제는 Google Cloud의 하이브리드 및 멀티클라우드 Kubernetes 관리 역량—특히 워크로드를 이동하지 않고 서로 다른 환경(on-prem, Google Cloud, AWS)에서 실행되는 클러스터 전반에 걸친 중앙집중식 정책/구성 관리, service mesh, 그리고 observability를 테스트합니다. 정답이 맞는 이유: GKE Enterprise는 환경 전반에 걸친 Kubernetes 클러스터 플릿(fleet)을 관리하도록 설계되었습니다. 이는 on-prem(대개 Google Distributed Cloud를 통해), Google Cloud(GKE), 그리고 다른 클라우드(예: AWS 포함) 전반에서 일관된 거버넌스와 운영을 위한 단일 control plane 경험을 제공합니다. “단일, 중앙집중식 플랫폼”과 “policies, configurations, service mesh, and observability” 요구사항은 GKE Enterprise의 fleet management 및 Anthos 기반(heritage)에 정확히 대응하며, 워크로드 재배치 없이 표준화를 가능하게 합니다. 주요 기능 / Best Practices: - Fleet management: 클러스터를 fleet에 등록하여 중앙집중식 관리와 일관성을 확보합니다. - Policy and configuration: Policy Controller(OPA/Gatekeeper)와 Config Management를 사용해 원하는 상태(desired state)(예: namespaces, RBAC, resource constraints)를 모든 클러스터에 걸쳐 강제하고 동기화합니다. - Service mesh: Anthos Service Mesh(Istio 기반)는 클러스터 전반에서 일관된 트래픽 관리, mTLS, 그리고 서비스 간 observability를 제공합니다. - Observability: fleet 전반에서 중앙집중식 telemetry, dashboards, tracing 통합(일반적으로 Cloud Operations suite를 통해)을 제공합니다. - Architecture Framework 정렬: 이기종 환경 전반에서 운영 우수성(표준화된 운영), 보안(policy enforcement, mTLS), 신뢰성(일관된 rollout 패턴)을 개선합니다. 흔한 오해: Cloud Run 또는 Cloud Functions는 운영을 단순화하므로 선택될 수 있지만, 이들은 serverless compute 플랫폼이지 멀티클러스터 관리 계층이 아닙니다. Compute Engine은 인프라 compute이며 Kubernetes fleet 거버넌스, mesh, 또는 중앙집중식 policy management를 제공하지 않습니다. 시험 팁: “hybrid/multi-cloud Kubernetes”, “centralized governance”, “policy/config consistency”, “service mesh across clusters”를 보면 GKE Enterprise(Anthos capabilities)를 떠올리세요. 또한 “without relocating workloads”라는 명시적 제약은 마이그레이션이나 단일 환경 compute 서비스가 아니라 management plane을 가리킵니다.

문제 3

Your 12-person logistics startup must add image label detection for 50,000 product photos per month and sentiment analysis on 5,000 support emails per week within 30 days and without hiring any new staff; how do Google Cloud's out-of-the-box AI APIs make AI/ML adoption feasible for your team?

문제 분석

핵심 개념: 이 문제는 Google Cloud의 사전 학습된, 즉시 사용 가능한 AI 서비스(흔히 “AI APIs”라고 부름)를 평가합니다. 예를 들어 이미지 라벨 감지를 위한 Cloud Vision API, 감성 분석을 위한 Natural Language API(또는 Vertex AI 언어 기능) 등이 있습니다. 이러한 서비스는 REST/gRPC 엔드포인트와 클라이언트 라이브러리를 제공하는 관리형 서비스로, 팀이 모델을 구축하거나 학습하지 않고도 AI 기능을 추가할 수 있게 해줍니다. 정답인 이유: 소규모 스타트업은 두 가지 AI 기능을 빠르게(30일 이내) 제공해야 하며 ML 전문가를 채용하지 않아야 합니다. Google Cloud의 사전 학습된 API는 정확히 이런 시나리오를 위해 설계되었습니다. 데이터(이미지 또는 텍스트)를 API로 전송하면 즉시 예측(라벨 또는 감성)을 반환받습니다. 커스텀 모델 개발 라이프사이클(데이터 라벨링, feature engineering, 학습, hyperparameter tuning, 평가, 배포, 모니터링)이 필요하지 않습니다. 이는 time-to-value와 운영 부담을 크게 줄여주며, 관리형 서비스를 사용해 차별화되지 않는 무거운 작업(undifferentiated heavy lifting)을 줄이라는 Google Cloud Architecture Framework 원칙과도 부합합니다. 주요 기능: 1) 사전 학습된 모델: Vision 라벨 감지와 감성 분석이 out-of-the-box로 동작합니다. 2) 간단한 통합: 클라이언트 라이브러리, REST 호출, IAM으로 제어되는 service account. 3) 확장성: API는 월/주 단위 배치 워크로드를 처리하도록 확장됩니다. Cloud Run/Functions + Cloud Scheduler로 배치 작업을 실행하거나, 더 큰 파이프라인에는 Dataflow를 사용할 수 있습니다. 4) 거버넌스 및 보안: IAM 권한(least privilege), audit logs, 그리고 데이터 유출(data exfiltration) 보호를 위한 선택적 VPC Service Controls. 5) 비용 모델: 요청/처리 단위당 pay-per-use 과금으로, 월 50,000장 이미지와 주 5,000건 이메일 같은 변동성 워크로드에 매력적입니다. 흔한 오해: 일부는 “AI”가 항상 커스텀 학습(D)을 필요로 한다고 가정하거나, 관리형 AI가 데이터 준비(B)의 필요성을 없앤다고 생각합니다. 실제로는 유효한 입력(올바른 이미지 포맷, 텍스트 인코딩, 언어 고려사항)을 제공하고 품질 검사를 처리해야 하지만, 모델을 만들 필요는 없습니다. 또 다른 오해는 AI APIs가 보안 요구사항(C)을 줄인다는 것인데, 실제로는 여전히 적절한 IAM 및 데이터 처리 통제가 필요합니다. 시험 팁: Digital Leader 문제에서는 비즈니스 제약(소규모 팀, 빠른 일정, 채용 없음)을 관리형 서비스와 사전 학습된 API에 매핑하세요. OCR, 라벨링, 번역, 감성, 엔터티 추출, speech-to-text 같은 작업이 보이면, 커스텀 ML 개발이 비현실적인 경우 대개 Google의 out-of-the-box AI APIs 또는 Vertex AI pre-built 오퍼링이 최선의 답입니다.

문제 4

A national bike-sharing consortium needs to publish real-time docking station availability (updated every 2 seconds) from 300 municipal operators and simultaneously receive rider rental/return events in real time to forward to each operator’s system. They require a standardized, secure, versioned interface over HTTPS that supports authentication and partner-specific rate limits; what should they implement?

문제 5

Your team operates a ride-sharing analytics service on Google Cloud across us-central1 and europe-west1, aiming for 99.9% monthly availability and 95th-percentile request latency under 300 ms during peak 18:00–22:00 traffic; within the SRE framework, which concept represents the metric that actually quantifies how well the service is performing?

문제 분석

핵심 개념: 이 문제는 Site Reliability Engineering (SRE)에서 신뢰성 측정 용어인 SLI, SLO, SLA를 테스트합니다. Google의 SRE 모델에서는 먼저 “좋음(good)”이 무엇인지(목표)를 정의한 다음, 실제 성능을 정량화하는 구체적인 측정값을 선택합니다. 정답이 맞는 이유: Service-level indicator (SLI)는 서비스가 얼마나 잘 동작하는지를 실제로 정량화하는 메트릭입니다. 예로는 가용성(성공한 요청의 %), 요청 지연 시간(예: 95th percentile이 300 ms 미만), 오류율, 처리량 등이 있습니다. 문제는 “서비스가 얼마나 잘 수행되는지를 실제로 정량화하는 메트릭”을 묻고 있으며, 이는 SLI의 정의와 정확히 일치합니다. 시나리오에서 월간 가용성과 피크 시간대의 p95 latency 측정값은 SLI입니다. 주요 특징 / Best Practices: 실무에서 SLI는 텔레메트리(Cloud Monitoring metrics, logs-based metrics, traces)로부터 계산되며, 다음을 만족해야 합니다: - 사용자 중심(User-centric)이어야 함(사용자가 경험하는 것을 측정: 예, 성공한 요청, end-to-end latency). - 명확히 정의되어야 함(무엇을 “성공”으로 볼지, 어떤 endpoint, 어떤 region, 18:00–22:00 같은 어떤 time window). - error budgets(SLO에서 도출됨)와 연결되어 release velocity와 reliability 간의 균형을 안내해야 함. multi-region 서비스(us-central1 및 europe-west1)의 경우, 팀은 종종 region별 및 전역(global) SLI를 정의하고, 측정이 트래픽 분포와 failover 동작을 반영하도록 보장합니다. 흔한 오해: 문제에 목표치(99.9% 및 p95 < 300 ms)가 포함되어 있어 SLI와 SLO를 혼동하는 경우가 많습니다. 이러한 목표치는 SLO이지만, 그 기반이 되는 측정 대상(가용성, latency percentile)은 SLI입니다. 또 다른 혼동은 SLA인데, SLA는 외부 계약이며 페널티를 포함할 수 있고, 내부 측정 자체가 아닙니다. 시험 팁: 다음 매핑을 암기하세요: SLI = “측정하는 것,” SLO = “측정값에 대한 목표,” SLA = “고객 대상 계약.” 질문이 메트릭/측정값을 묻는다면 SLI를 고르고, 목표/임계값을 묻는다면 SLO를 고르며, 계약상 보장을 묻는다면 SLA를 고르세요. 이는 Google Cloud Operations/SRE 관행 및 Google Cloud Architecture Framework의 reliability pillar(측정 가능한 목표와 모니터링)와 일치합니다.

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

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

문제 6

Your global e-commerce platform ingests clickstream and ad-impression events from 180 million monthly active users across 5 regions (NA, EU, APAC, LATAM, MEA). At peak, the system must handle at least 1.2 million writes per second with sub-10 ms write latency, store petabyte-scale wide-column time-series data, and scale horizontally without complex schema migrations. Which Google Cloud product should you choose?

문제 분석

핵심 개념: 이 문제는 페타바이트 규모의 wide-column time-series 데이터를 초고처리량, 저지연으로 ingest하기 위해 적절한 managed database를 선택하는지를 평가합니다. 핵심 신호는 1.2M writes/sec, 10 ms 미만 write latency, wide-column 모델, horizontal scaling, 그리고 복잡한 schema migration을 피하는 것입니다. 정답이 맞는 이유: Cloud Bigtable은 Google Cloud의 managed wide-column NoSQL database로, 대규모 확장과 read/write에서 일관된 single-digit millisecond latency를 위해 설계되었습니다. time-series, clickstream, ad-tech, IoT telemetry, personalization event store에 흔히 사용됩니다. Bigtable은 node를 추가하여 수평 확장하며, throughput이 node 수에 비례해 선형적으로 증가하므로 여러 region에 걸쳐 1.2M writes/sec 같은 지속적인 높은 write rate에 적합합니다. 주요 기능 / Best Practices: Bigtable의 schema는 sparse하고 유연하며(column families/qualifiers), 이는 이벤트 속성이 진화하더라도 파괴적인 migration 없이 지원합니다. row key를 올바르게 설계하면 높은 write throughput에 최적화됩니다(예: monotonically increasing timestamp로 인한 hotspotting을 피하기 위한 time-bucketing 또는 salting/hashing). regional resilience와 더 낮은 latency 접근을 위해 replication(multi-cluster routing)을 사용할 수 있어 global architecture와 정렬됩니다. Bigtable은 streaming ingestion(종종 Pub/Sub + Dataflow를 통해) 및 analytics(BigQuery federation/exports)와 잘 통합되어 end-to-end data transformation pipeline을 지원합니다. 흔한 오해: Firestore도 NoSQL이며 globally distributed이지만, document database로서 scaling 특성과 한계가 다릅니다. million-writes/sec 수준의 petabyte-scale wide-column time-series에 대한 전형적인 선택은 아닙니다. Cloud SQL은 relational이며 이 규모에서 요구되는 horizontal scaling과 write-latency 요구사항을 충족하지 못합니다. Cloud Data Fusion은 integration/ETL 도구이지 serving database가 아닙니다. Exam Tips: “wide-column”, “time-series”, “petabyte-scale”, “massive throughput과 함께 single-digit ms latency”를 보면 Cloud Bigtable을 떠올리세요. relational OLTP는 Cloud SQL/Spanner, document/mobile/web app 데이터는 Firestore, ETL/orchestration은 Data Fusion을 선택합니다. 또한 Bigtable 성능은 row-key 설계와 node sizing/quotas에 크게 좌우되며, replication은 강한 multi-row transaction보다는 multi-region availability를 위해 사용된다는 점을 기억하세요.

문제 7

Your agriculture analytics company has 200,000 labeled PNG images of crop leaves in a Cloud Storage bucket and needs to train a custom model to classify each image into 8 disease categories within two weeks using a fully managed service without writing model code. Which Google Cloud product or service should you use?

문제 분석

핵심 개념: 이 문제는 모델 코드를 작성하지 않고도 라벨링된 이미지로부터 커스텀 이미지 분류 모델을 학습할 수 있는 완전 관리형 Google Cloud AI 서비스를 선택하는지를 평가합니다. Google Cloud에서는 Vertex AI의 AutoML 기능(시험에서는 일반적으로 AutoML Vision으로 언급됨)이 이에 해당합니다. 정답인 이유: AutoML Vision은 Cloud Storage에 저장된 라벨링된 데이터셋을 사용해 이미지(분류, 객체 감지)에 대한 지도 학습을 수행하도록 설계되었습니다. 회사는 이미 200,000개의 라벨링된 PNG 이미지를 보유하고 있으며 8개 클래스 분류기가 필요합니다. AutoML Vision은 엔드투엔드 워크플로를 제공합니다: Cloud Storage에서 데이터 가져오기, 라벨 정의, 학습/검증/테스트 세트 자동 분할, 모델 학습, 지표 평가, 그리고 온라인 예측 또는 배치 예측을 위한 배포까지—팀이 모델 아키텍처나 학습 코드를 구현할 필요가 없습니다. “2주 이내” 요구사항은 Google의 인프라와 내부적으로 GPU/TPU를 활용해 확장 가능한 관리형 학습과도 잘 부합합니다. 주요 기능 / 모범 사례: AutoML Vision (Vertex AI AutoML)은 대규모 데이터셋을 지원하고, 일반적인 전처리를 처리하며, 8개 질병 카테고리 전반의 성능을 검증할 수 있도록 모델 평가(혼동 행렬, precision/recall)를 제공합니다. 모범 사례로는 라벨 품질 보장, 클래스 균형 유지(또는 데이터 증강/추가 수집으로 불균형 완화), Cloud Storage 구성 규칙 활용이 있습니다. 프로덕션에서는 대규모 백필에는 배치 예측을, 실시간 분류에는 온라인 엔드포인트를 고려하세요. 또한 리전 가용성(Vertex AI는 리전 기반)과 비용 통제(학습 및 예측은 과금되며, 대규모 데이터셋은 학습 시간/비용 증가)를 계획해야 합니다. 흔한 오해: 사람들은 “노코드” ML을 BigQuery ML과 혼동할 수 있지만, BQML은 주로 구조화/정형 데이터에 대한 SQL 기반 모델링에 적합하며 PNG로부터의 이미지 분류에는 적합하지 않습니다. Video Intelligence API는 비디오 콘텐츠 분석용이지 커스텀 이미지 분류기를 학습하는 용도가 아닙니다. Looker는 BI/시각화 도구이며 ML 모델을 학습하지 않습니다. 시험 팁: “Cloud Storage의 라벨링된 이미지”, “커스텀 모델”, “모델 코드 없음”을 보면 Vertex AI AutoML (AutoML Vision)을 떠올리세요. 입력이 비디오라면 Video Intelligence를, BigQuery의 정형 데이터를 SQL로 다룬다면 BigQuery ML을, 대시보드라면 Looker를 고려하세요. 데이터 모달리티(이미지)를 올바른 관리형 AI 제품에 매핑하는 것이 핵심입니다.

문제 8

An urban bike-sharing startup managing 2,500 bikes across 120 stations wants to improve rider satisfaction over the next quarter. Over the past 6 months, they collected 500 user submissions via an in-app 'Report an issue' form, IoT telemetry from bike locks every 5 seconds, and daily station fill-level summaries. To decide where to prioritize improvements, which of the following represents unstructured data they can analyze?

문제 분석

핵심 개념: 이 문제는 분석을 위한 데이터 분류(정형 vs 반정형 vs 비정형)를 테스트합니다. Google Cloud 시험 맥락에서는 이는 적절한 저장/분석 도구를 선택하는 것(예: 정형/반정형에는 BigQuery, 비정형 텍스트에는 NLP/Vertex AI)과 “비정형(unstructured)”의 의미를 이해하는 것과 연결됩니다. 정답이 맞는 이유: 비정형 데이터는 미리 정의된 행/열 스키마를 따르지 않으며, 상당한 전처리 없이 관계형 테이블로 쉽게 표현하기 어려운 정보입니다. 사용자로부터 받은 자유 형식의 이슈 설명은 전형적인 비정형 데이터입니다. 각 제출물은 길이, 어휘, 문법, 내용이 제각각일 수 있습니다. 이 텍스트를 분석(예: 불만 클러스터링, 감성 분석, 토픽 추출)하면 라이더 만족도를 개선하기 위한 우선순위 결정에 직접적으로 도움이 됩니다. 주요 특징 / Google Cloud에서의 분석 방식: 비정형 텍스트는 일반적으로 Natural Language Processing (NLP)로 분석합니다. Google Cloud에서는 팀이 원본 제출물을 Cloud Storage 또는 Firestore에 저장한 뒤, 메타데이터와 인덱싱을 위해 BigQuery를 사용하고, entity extraction, sentiment analysis, classification을 위해 Vertex AI / Natural Language APIs를 적용할 수 있습니다. 모범 사례는 원본 데이터를 immutable하게 유지하고, 파생된 정형 필드(토픽 라벨, 심각도 점수)를 추가한 다음, BigQuery에서 그 특징들을 정형 텔레메트리 및 스테이션 지표와 조인하여 전체적인 우선순위를 정하는 것입니다. 흔한 오해: 고빈도 텔레메트리(예: 5초마다 GPS)는 크고 빠르기 때문에 “비정형”처럼 느껴질 수 있지만, 보통은 정형 데이터입니다. 각 레코드는 일관된 필드(timestamp, lat, long, bike_id)를 갖습니다. 마찬가지로 일별 이용률 퍼센트도 명확한 정형 시계열 지표입니다. 재고 테이블은 가장 명백한 정형 관계형 데이터입니다. 시험에서는 종종 “복잡함” 또는 “대규모”와 “비정형”을 구분합니다—volume/velocity가 데이터의 비정형성을 의미하지는 않습니다. 시험 팁: 비정형 데이터를 식별하라고 하면 자유 형식 텍스트, 이미지, 오디오, 비디오, PDF, 소셜 게시물을 찾으세요. 좌표, 퍼센트, SKU처럼 일관된 컬럼을 가진 숫자 필드가 보이면 정형 데이터입니다(또는 JSON이라면 기껏해야 반정형). 또한 비정형 데이터는 종종 AI/ML (Vertex AI)의 도움을 받아 구조를 추출한 뒤, BigQuery에서 정형 데이터셋과 함께 분석하는 것이 유리하다는 점을 기억하세요.

문제 9

A 120-employee nonprofit is conducting a quarterly security readiness review and notes that during the last 30 days, 3 simulated lures were sent and 26% of staff clicked the links; the CISO wants to prioritize controls for social-engineering risks specifically. Which of the following is the most plausible method an attacker would use to carry out a social-engineering attack in this context?

문제 분석

핵심 개념: 이 문제는 인간을 대상으로 한 공격 벡터로서의 social engineering(특히 phishing)에 대한 이해를 평가합니다. Google Cloud Digital Leader 관점에서는 보안 기본 사항(위협, risk management, credential theft 및 account compromise를 줄이는 controls)과 연결됩니다. 정답이 맞는 이유: 시나리오는 simulated lures와 click rate(26%)를 설명하는데, 이는 전형적인 phishing 대비(준비도) 테스트입니다. 이 맥락에서 실제 공격자가 사용할 가능성이 가장 높은 방법은 신뢰받는 내부 기능(예: payroll)을 사칭하는 기만적 이메일을 보내고, 사용자를 가짜 login form으로 유도해 credentials를 수집하는 것입니다. 이는 기술적 취약점을 직접 악용하기보다 인간의 신뢰를 조작하기 때문에 social-engineering 공격입니다. 주요 특징 / Best Practices(우선순위로 둘 controls): social-engineering risk를 줄이기 위해서는 identity 및 access controls와 사용자 보호를 우선시해야 합니다. Google 계정에 대해 phishing-resistant MFA(예: security keys/passkeys)를 강제하고, 강력한 email authentication(SPF, DKIM, DMARC)을 구현하며, 이메일에서 advanced phishing 및 malware protection을 사용하세요. least privilege와 conditional access 원칙(context-aware access)을 적용해, stolen credentials만으로는 악용 가치가 낮아지도록 합니다. Google Cloud에서는 centralized identity(Cloud Identity / Google Workspace), security monitoring 및 alerting(Security Command Center를 통한 cloud posture; 해당되는 경우 Workspace security investigations), 그리고 측정 가능한 성과를 동반한 지속적인 awareness training도 강조합니다. 흔한 오해: 학습자들은 종종 “security attack”과 “social engineering”을 혼동합니다. SQL injection과 DDoS는 흔한 cyberattack이지만, 사람을 조작하기보다는 시스템과 availability를 대상으로 합니다. 물리적 sabotage(랙 과열 유도)는 위협이 될 수 있으나, phishing simulation 지표가 시사하는 전형적인 “social engineering” 방법은 아닙니다. Exam Tips: “lures sent”, “click rate”, “credential entry”, “impersonation” 같은 지표가 보이면 phishing/social engineering을 떠올리세요. 공격을 보안 도메인에 매핑하세요: 인간 기만 → identity compromise → account takeover. 그다음 mitigations를 생각합니다: phishing-resistant MFA, email authentication, 사용자 교육, 그리고 blast radius를 제한하기 위한 least privilege.

문제 10

A metropolitan transit agency stores real-time vehicle locations and historical ridership data in a relational database (e.g., Cloud SQL). They want to create a new revenue stream by allowing third-party mobile app developers to use this data in their apps. They expect around 120,000 requests per day at peak and require usage-based billing without granting direct database access. Which cloud-first approach should the agency choose?

문제 분석

핵심 개념: 이 문제는 클라우드 우선 데이터 수익화와 안전한 공유 패턴을 평가합니다. 즉, 내부 데이터에 직접 데이터베이스 접근 권한을 부여하는 대신 API 계층(API management)을 통해 데이터를 노출하는 방식입니다. Google Cloud에서는 일반적으로 Cloud Run/Cloud Functions 또는 GKE에서 API를 호스팅하고, Apigee 또는 API Gateway를 앞단에 두어 인증, 할당량, 분석을 통해 과금 측정을 수행하는 형태로 매핑됩니다. 정답인 이유: 옵션 C는 모든 요구사항을 가장 잘 충족합니다: (1) 서드파티가 Cloud SQL에 직접 접근하지 않고도 데이터에 접근할 수 있고, (2) 요청을 인증 및 인가할 수 있으며, (3) 사용량을 측정하여 과금과 연계할 수 있고, (4) 프로덕션 데이터베이스를 보호하면서 피크 수요(하루 120,000 요청)까지 확장할 수 있습니다. API 파사드(API façade)는 소비자를 데이터베이스 스키마로부터 분리하고 제품화(플랜, 티어, 키, 계약)를 가능하게 합니다. 이는 Google Cloud Architecture Framework의 보안(least privilege), 신뢰성(system of record 보호), 비용 최적화(통제된 소비) 원칙과 일치합니다. 주요 기능 / 모범 사례: API management 계층(Apigee는 수익화 관점에서 대표적인 선택)을 사용해 개발자 키를 발급하고, OAuth2/JWT를 강제하며, 할당량/속도 제한을 적용하고, 소비자별 분석을 수집합니다. 캐싱(Apigee caching, Memorystore 또는 해당되는 경우 CDN)을 구현해 데이터베이스 부하를 줄이고 지연 시간을 개선합니다. API를 Cloud Armor/WAF 제어 뒤에 두고, API-데이터베이스 연결에는 IAM/service accounts를 사용합니다(예: Cloud SQL Auth Proxy/Connector). 프로덕션 워크로드를 격리하기 위해 read replicas 또는 별도의 서빙 datastore(예: 과거 분석용 BigQuery)를 고려합니다. 흔한 오해: 일부는 “read-only DB users만 주면 가장 간단하다”고 생각하지만, 이는 least privilege를 깨고 공격 표면을 늘리며, 감사(auditing)를 복잡하게 하고, 요청 단위 과금을 어렵게 만듭니다. 또 다른 오해는 공유를 위해 데이터베이스 유형 변경이 필요하다는 것인데, 그렇지 않습니다—스토리지 엔진보다 접근 패턴과 거버넌스가 더 중요합니다. 시험 팁: “서드파티 접근”, “직접 데이터베이스 접근 금지”, “사용량 기반 과금”이 보이면 인증 + 할당량 + 분석을 갖춘 “API product”를 떠올리세요. Digital Leader에서는 수동 내보내기나 핵심 데이터베이스를 직접 노출하는 방식보다 관리형 클라우드 우선 접근(API management)을 선택하세요.

Practice Test #1

3중 AI 검증 답안 및 해설

연습 문제

합격 후기(7)

다른 모의고사

Practice Test #2

Practice Test #3

지금 학습 시작하기