CloudPass LogoCloud Pass
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
Certifications
AWSGoogle CloudMicrosoftCiscoCompTIADatabricks
Google Professional Cloud Developer
Google Professional Cloud Developer

Practice Test #4

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

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

AI 기반

3중 AI 검증 답안 및 해설

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

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

기출 문제

1
문제 1

Your retail analytics team has an IoT gateway that uploads a 5 MB CSV summary every 10 minutes to a Cloud Storage bucket gs://retail-iot-summaries-prod. Upon each successful upload, you must notify a downstream pipeline via the Pub/Sub topic projects/acme/topics/iot-summaries so a Dataflow job can start. You want a solution that requires the least development and operational effort, introduces no additional compute to manage, and can be set up within 1 hour; what should you do?

정답입니다. Cloud Storage는 object finalize(OBJECT_FINALIZE) 알림을 Pub/Sub topic으로 직접 publish하도록 구성할 수 있습니다. 이는 코드가 필요 없고 관리할 compute도 없는 네이티브 통합으로, 최소 운영 노력과 빠른 설정 요구사항에 부합합니다. IAM에서 Cloud Storage service account가 topic에 publish할 수 있도록 허용하고, 다운스트림 consumer는 at-least-once delivery semantics를 고려해 설계하세요.

오답입니다. App Engine은 업로드를 수신한 뒤 Pub/Sub로 publish하는 애플리케이션 endpoint를 구축하고 배포해야 합니다. 이는 개발 시간, 운영 고려사항(버전, 스케일링 동작, 모니터링)을 추가하고, 수집 경로도 변경합니다(Cloud Storage에 직접 업로드하는 대신 앱으로 업로드). 최소 개발 및 추가 compute 관리 없음이라는 요구사항을 위반합니다.

이 문제의 제약 조건에서는 오답입니다. Cloud Storage finalize 이벤트로 트리거되는 Cloud Function이 Pub/Sub로 publish할 수는 있지만, 여전히 코드 작성/배포/운영이 필요합니다(런타임 구성, 재시도, 로깅/알림, function에 대한 IAM). Cloud Storage가 Pub/Sub로 직접 publish할 수 있으므로, 단순 알림에는 function이 불필요한 추가 구성 요소입니다.

오답입니다. GKE에서 서비스를 실행하면 운영 오버헤드가 가장 큽니다: cluster 프로비저닝, node 관리(Autopilot이어도 추가 설정은 필요), 배포, 스케일링, 보안 패치, 모니터링이 필요합니다. 또한 업로드 흐름을 서비스로 보내도록 변경해야 합니다. 이는 “1시간 이내” 및 “추가 compute 관리 없음” 요구사항과 거리가 멉니다.

문제 분석

핵심 개념: 이 문제는 운영 오버헤드를 최소화하면서 Cloud Storage와 Pub/Sub 간의 이벤트 기반 통합을 테스트합니다. 핵심 기능은 Cloud Storage 이벤트 알림(object finalize)으로, 중간에 어떤 컴퓨팅도 실행하지 않고도 Pub/Sub topic으로 직접 publish할 수 있어, Dataflow 같은 다운스트림 시스템이 새 object에 반응할 수 있습니다. 정답이 맞는 이유: bucket이 OBJECT_FINALIZE 알림을 Pub/Sub로 보내도록 구성하는 것이 개발과 운영 측면에서 가장 부담이 적은 접근입니다. 코드가 필요 없고, 배포할 런타임도 없으며, 컴퓨팅의 스케일링/패치/모니터링도 필요 없습니다. 빠르게(대개 몇 분 내) 구성할 수 있고, finalize 이벤트는 bucket에서 object가 성공적으로 생성/덮어쓰기될 때 발생하므로 “각 업로드가 성공할 때마다”라는 요구사항을 충족합니다. 주요 기능 / 구성 / 모범 사례: - gs://retail-iot-summaries-prod에 대해 OBJECT_FINALIZE용 Cloud Storage Pub/Sub notifications를 사용합니다. - Pub/Sub topic이 올바른 project(projects/acme/topics/iot-summaries)에 존재하는지 확인하고, Cloud Storage service account에 해당 topic에 publish할 권한(pubsub.publisher)을 부여합니다. - 다운스트림에서 필터링/중복 처리를 고려합니다: storage notifications는 at-least-once delivery이므로 Dataflow 트리거 로직은 idempotent해야 합니다(예: object name + generation으로 dedupe). - 알림에 object metadata(bucket, objectId, generation)를 포함해 Dataflow가 정확한 파일을 찾을 수 있게 합니다. 흔한 오해: Cloud Functions(option C)도 serverless이지만, 코드 작성, 배포, function runtime에 대한 IAM, 재시도, 그리고 cold-start/관측성 오버헤드가 추가됩니다. App Engine과 GKE는 운영 부담이 더 크며, Cloud Storage가 이미 Pub/Sub 이벤트를 직접 emit할 수 있으므로 불필요합니다. 시험 팁: 요구사항이 “최소 개발,” “추가 compute 없음,” “빠른 설정”을 강조할 때는 glue code를 작성하기보다 managed integration(네이티브 이벤트 알림)을 우선 선택하세요. Cloud Storage → Pub/Sub notifications는 대표적인 통합 패턴이며, publish 전에 변환/검증/라우팅/보강이 필요한 경우에만 Cloud Functions를 사용하세요.

2
문제 2

Your startup manages 3,000 smart vending machines that publish 4 KB JSON telemetry to a Pub/Sub topic at an average rate of 600 messages per second (peaks up to 1,200). You must parse each message and persist it for analytics with end-to-end latency under 45 seconds, and each message must be processed exactly once to avoid double-counting transactions. You want the cheapest and simplest fully managed approach with minimal operations overhead and cannot maintain clusters or build custom deduplication workflows. What should you do?

반복 Dataproc job은 배치 지향이며, 매우 엄격한 <45초 end-to-end 지연 시간 SLA를 충족하려면 극도로 자주 실행해야 하는데 이는 비용과 복잡도를 증가시킵니다. Dataproc는(일시적이라 하더라도) 클러스터 관리가 수반되어 “클러스터를 유지할 수 없다”는 조건과 충돌합니다. 또한 Pub/Sub에서 배치로 pull하는 방식은 offset 관리와 exactly-once 보장을 추가 상태 처리 없이 달성하기 어렵게 만들 수 있습니다.

Dataflow streaming은 완전 관리형이며 autoscaling을 지원하고, 낮은 지연 시간으로 Pub/Sub 수집을 처리하도록 설계되었습니다. Apache Beam의 PubsubIO가 깔끔하게 통합되며, Dataflow는 checkpointing을 통한 fault tolerance를 제공하므로 파이프라인 내에서 메시지가 중복 집계되지 않습니다. Cloud Storage로의 windowed writes는 운영 오버헤드를 낮게 유지하면서 효율적인 downstream 분석 워크플로를 지원하고 45초 지연 시간 요구사항을 충족합니다.

Pub/Sub 트리거 Cloud Functions는 at-least-once delivery를 제공하므로 retry, timeout, transient error 동안 중복이 발생할 수 있습니다. 따라서 Functions에서 BigQuery로 직접 쓰면 idempotency 또는 deduplication을 구현하지 않는 한 중복 집계가 발생할 수 있습니다. 이 선택지는 daily dedup query에 명시적으로 의존하는데, 이는 “exactly once” 요구사항을 위반하며 분석의 <45초 end-to-end 정확성 요구사항도 충족하지 못합니다.

이 설계는 불필요한 복잡성과 운영 오버헤드를 추가합니다. Bigtable에 기록한 뒤 두 번째 스트리밍 파이프라인을 실행해 중복을 제거하는 것은 문제에서 금지한 커스텀 deduplication 워크플로에 해당합니다. 또한 비용(Bigtable 인스턴스 + 두 개의 파이프라인)을 증가시키고 더 많은 장애 지점과 지연 시간을 유발합니다. Dataflow는 이러한 2단계 접근 없이 exactly-once 처리를 수행할 수 있습니다.

문제 분석

핵심 개념: 이 문제는 낮은 지연 시간 SLA와 exactly-once 처리 시맨틱을 만족하는 완전 관리형 스트리밍 수집 및 처리 아키텍처를 선택하는지를 평가합니다. 핵심 서비스는 수집을 위한 Pub/Sub와 관리형 스트림 처리를 위한 Dataflow (Apache Beam), 그리고 분석용 sink입니다. 정답이 맞는 이유: Pub/Sub에서 읽고 윈도우 기반 출력을 Cloud Storage에 쓰는 Dataflow 스트리밍 파이프라인은 선택지 중 <45초 end-to-end 지연 시간 요구사항을 충족하면서 파이프라인 내 exactly-once 처리 보장을 제공할 수 있는 가장 단순한 완전 관리형 옵션입니다. Dataflow는 checkpointing, autoscaling, fault-tolerant 처리를 제공합니다. 소스로 Pub/Sub를 사용할 때 Dataflow는 각 메시지가 파이프라인에서 한 번만 처리되도록 보장할 수 있으며(커스텀 dedup 워크플로 불필요), downstream 분석을 위해 Cloud Storage에 결정적인(deterministic) 윈도우 파일을 생성할 수 있습니다(예: BigQuery로 배치 로드 또는 Dataproc Serverless/BigQuery external tables를 통한 처리). 핵심 기능 / 구성 / 모범 사례: - Pub/Sub 소스를 사용하는 Dataflow streaming을 사용하고 효율성을 위해 streaming engine을 활성화합니다. - event-time 처리를 fixed windows(예: 1-minute)와 함께 사용하고, 디바이스 clock skew에 맞는 allowed lateness를 설정합니다. - Cloud Storage에는 windowed writes(예: file-per-window + sharding)로 기록하여 파일 크기를 적절히 유지하고 small-file 문제를 방지합니다. - 피크 트래픽 기준 sizing: 1,200 msg/s * 4 KB ≈ 4.8 MB/s로 Pub/Sub 및 Dataflow 처리량 범위 내이며, Dataflow autoscaling이 burst를 처리합니다. - Exactly-once: Dataflow의 checkpointing과 replay 처리로 파이프라인 내 중복 처리를 방지합니다. sink가 idempotency를 지원하지 않는 한 non-idempotent side effects는 피합니다. 흔한 오해: - “Cloud Functions가 더 단순하다”: 운영 측면에서는 단순하지만, Pub/Sub 트리거 함수는 exactly-once를 보장하지 않습니다(at-least-once delivery). 따라서 deduplicate가 필요하며, 이는 문제에서 금지합니다. - “Dataproc job이 더 저렴하다”: 반복 배치 job은 지연 시간을 증가시키고 클러스터 운영(또는 최소한 job orchestration)이 필요하며, 45초 스트리밍 SLA를 자연스럽게 만족하지 못합니다. - “Bigtable을 쓰고 나중에 dedupe한다”: 추가 파이프라인과 커스텀 dedup 로직을 도입하게 되어, 최소 운영 및 커스텀 dedup 워크플로 금지 요구사항을 위반합니다. 시험 팁: - Pub/Sub 스트리밍에서 낮은 지연 시간과 최소 운영이 요구되면 기본 선택은 Dataflow입니다. - 요구사항에 “exactly once”가 있고 커스텀 dedup를 금지하면, sink가 본질적으로 idempotent이고 설계에서 unique keys를 명시적으로 사용하는 경우가 아니라면 Cloud Functions/Cloud Run consumer는 피합니다. - 요구사항을 Google Cloud Architecture Framework에 매핑하세요: operational excellence(관리형 서비스), reliability(checkpointing/retries), performance(autoscaling), cost(always-on 클러스터 회피).

3
문제 3

You are migrating a MySQL table named AccountActivity to Cloud Bigtable. The table schema includes Account_id, Event_timestamp, Transaction_type, and Amount, with a primary key defined as (Account_id, Event_timestamp). To ensure efficient data modeling and query performance in Bigtable, how should you design the row key?

Account_id만 사용하면 account별로 데이터를 묶을 수는 있지만, account당 여러 event에 대한 유일성을 제공하지 못합니다. Bigtable에서 각 row key는 단일 row를 식별하므로, 동일한 row key로 반복 write를 하면 cell이 overwrite되거나(또는 복잡한 qualifier가 필요) 시간 범위 쿼리가 비효율적이 됩니다. 또한 time이 key에 포함되지 않으므로 특정 시간 window에 대한 직관적인 scan이 불가능합니다.

Account_id와 Event_timestamp를 연결하는 방식은 관계형 primary key와 일반적인 접근 패턴(시간에 따른 특정 account의 활동 조회)에 가장 잘 부합합니다. Bigtable은 row key로 정렬된 상태로 row를 저장하므로, 이 설계는 Account_id 기준의 효율적인 prefix scan과 account 내부에서 timestamp 기준의 range scan을 가능하게 합니다. 또한 event별 유일성을 유지하고, account의 이력이 테이블 전반에 흩어지는 것을 방지합니다.

Event_timestamp 다음에 Account_id를 연결하면 전역적인 시간 기반 scan에는 최적화되지만, 단일 account의 event가 여러 key range에 분산되므로 account별 쿼리를 효율적으로 수행할 수 없습니다. 또한 timestamp가 증가하는 형태이고 많은 write가 동일한 tablet range에 몰리면 hotspotting을 유발할 수 있습니다. 기본값으로는 대개 좋지 않으며, 주요 쿼리가 “특정 시간 범위의 모든 account”인 경우에만 적합합니다.

Event_timestamp만 사용하는 것은 여러 account가 같은 시각에 event를 생성할 때 row를 유일하게 식별할 수 없다는 점에서 문제가 됩니다. 또한 account별 lookup이 비효율적입니다. 더불어 단조 증가 key로 인해 심각한 hotspotting 위험이 있으며, write가 소수의 tablet에 집중될 수 있습니다. 이 설계는 지배적인 쿼리가 엄격히 시간 순서이고 유일성이 다른 방식으로 처리되는 특수한 경우에만 적합합니다.

문제 분석

핵심 개념: 이 문제는 Cloud Bigtable 데이터 모델링, 특히 row key 설계를 평가합니다. Bigtable은 row key 기준의 빠른 조회와 range scan에 최적화된 wide-column NoSQL 데이터베이스입니다. row key를 사전식(lexicographic)으로 정렬해 행을 저장하며, 접근 패턴이 스키마 설계를 주도해야 합니다. 정답이 맞는 이유: 관계형 primary key는 (Account_id, Event_timestamp)이며, 이는 지배적인 접근 패턴이 특정 account의 활동을(대개 시간 범위로) 조회하는 것임을 의미합니다(예: “account 123의 최근 30일”). Bigtable에서는 이러한 읽기를 연속적인 scan으로 수행할 수 있도록 row key를 설계하는 것이 최선입니다. Account_id + Event_timestamp를 연결하는 방식(선택지 B)은 동일한 account의 모든 event를 함께 묶어 Account_id로 효율적인 prefix scan을 가능하게 하고, 그 prefix 내부에서 timestamp로 range scan을 가능하게 합니다. 이는 Bigtable 모범 사례(가장 흔한 쿼리에 맞고 순차 읽기를 가능하게 하는 row key 선택)와 일치합니다. 주요 기능 / 모범 사례: - Lexicographic ordering: Account_id를 앞에 두면 해당 account의 모든 row가 인접하게 배치됩니다. - Range scans: Account_id를 prefix로 사용하면 Account_id#startTime부터 Account_id#endTime까지 scan할 수 있습니다. - Hotspotting 고려: write가 소수의 account에 심하게 편중되면 salting/hashing이 필요하거나 “최신 우선” 읽기를 위해 timestamp 부분을 reverse해야 할 수 있습니다. 하지만 주어진 선택지 중에서는 B가 올바른 기본 모델입니다. - Bigtable timestamps: Bigtable은 timestamp가 있는 cell version을 제공하지만, 이를 event time 모델링에 의존하면 안 됩니다. event time은 쿼리 가능성을 위해 row key(또는 column)에 포함되어야 합니다. 흔한 오해: - Account_id만 사용하는 것(A)은 partition key와 맞아 보이지만, account당 여러 event를 유일하게 표현할 수 없고 overwrite 또는 복잡한 column qualifier를 강제합니다. - Event_timestamp를 앞에 두는 것(C/D)은 시간 기반 쿼리에 좋아 보일 수 있지만, 단일 account의 event가 테이블 전반에 흩어져 배치되며, 많은 event가 시간 순으로 유입될 때 write hotspot을 만들 수 있습니다. 시험 팁: Bigtable에서는 항상 “주요 lookup은 무엇이며 어떤 range scan이 필요한가?”부터 시작하세요. 가장 높은 cardinality의 grouping key(대개 entity ID)를 먼저 두고, 그 entity 내부 정렬을 위한 time component를 뒤에 둡니다. key가 단조 증가(monotonically increasing)하는 경우(timestamp) hotspotting을 주의하고, 필요 시 salting 또는 time reverse를 고려하세요.

4
문제 4

You are a developer at a nationwide logistics platform. The company operates an on-premises dispatch system backed by PostgreSQL to store driver profiles and delivery logs. As part of a migration to Google Cloud, your team will move driver profile data to Cloud Firestore while delivery logs will also be stored in Firestore going forward. The system has 120,000 active drivers; each driver can create up to 200 delivery log entries per day from mobile devices that must support offline sync and per-driver access control. You also need efficient per-driver queries and occasional analytics that query across all drivers' logs. You are tasked with designing the Firestore collections. What should you do?

두 개의 루트 컬렉션(drivers와 deliveryLogs)도 가능하지만, 드라이버별 접근 제어와 드라이버별 쿼리가 덜 자연스럽습니다. 일반적으로 각 로그에 driverId 필드가 필요하고, 보안을 필드 체크로 강제해야 하는데 이는 경로 기반 규칙보다 오류가 발생하기 쉽습니다. 또한 클라이언트가 매우 큰 전역 logs 컬렉션을 자주 필터링해야 한다면 비효율적인 쿼리로 이어질 수 있고, 순차적 ID를 사용할 경우 hot spot 위험이 커질 수 있습니다.

이는 권장되는 모델입니다. drivers를 루트 컬렉션으로 두고 logs를 각 드라이버 아래의 서브컬렉션으로 둡니다. 1:N 관계(드라이버 1명, 로그 다수)에 부합하고, 효율적인 드라이버별 쿼리를 지원하며, 문서 경로 기반의 단순하고 강력한 Security rules를 가능하게 합니다. 오프라인 동기화도 클라이언트가 자신의 서브트리만 동기화하므로 잘 동작합니다. 드라이버 간 분석이 필요하면 logs 서브컬렉션에 대한 collection group query를 사용하거나 BigQuery로 export하세요.

배송 로그를 드라이버 프로필 문서 내부의 중첩 리스트/배열로 저장하는 것은 Firestore anti-pattern입니다. 문서는 1 MiB 크기 제한이 있으며, 로그는 지속적으로 증가(하루 최대 200개)하므로 빠르게 제한을 초과합니다. 큰 배열은 한 요소를 업데이트해도 문서 전체를 다시 쓰게 되어 write amplification이 커지고, 경합이 증가하며, 오프라인 동기화와 성능에 악영향을 줍니다. 또한 로그에 대한 효율적인 쿼리(예: 날짜/상태 기준)를 불가능하게 합니다.

배송 로그를 루트로 만들고 각 드라이버 프로필을 서브컬렉션으로 두는 것은 접근 패턴에 비해 부자연스러운 계층입니다. 드라이버 프로필은 상위 엔터티이며 로그와 독립적으로 접근되므로, 이를 로그 아래에 중첩하면 읽기와 Security rules가 복잡해집니다. 또한 로그 경로를 알지 못하면 드라이버 프로필을 가져오기 어려워집니다. 이 설계는 Firestore 모델링 모범 사례와 맞지 않습니다.

문제 분석

핵심 개념: 이 문제는 확장성, 보안, 오프라인 동기화, 그리고 쿼리 패턴을 고려한 Firestore 데이터 모델링을 평가합니다. Firestore는 계층형 데이터(컬렉션/문서/서브컬렉션), 클라이언트 측 오프라인 지속성, 그리고 문서 경로를 기준으로 접근 범위를 제한하는 보안 규칙에 최적화된 문서 데이터베이스입니다. 정답이 맞는 이유: 드라이버 프로필을 위한 루트 컬렉션(예: drivers/{driverId})을 사용하고, 각 드라이버 아래에 배송 로그를 위한 서브컬렉션(예: drivers/{driverId}/logs/{logId})을 두는 방식이 적절합니다. 이는 주요 접근 패턴인 “드라이버별 쿼리”와 “드라이버별 접근 제어”에 데이터를 정렬합니다. 이 모델에서는 모바일 클라이언트가 자신의 로그만 효율적으로 쿼리할 수 있으며(서브컬렉션 내 단일 컬렉션 쿼리), 보안 규칙으로 로그인한 드라이버가 자신의 문서 경로 아래에서만 읽기/쓰기를 하도록 강제할 수 있습니다. 오프라인 동기화도 클라이언트가 접근하는 특정 문서/컬렉션을 동기화하기 때문에 자연스럽게 동작합니다. 주요 기능 / 모범 사례: - Security rules: 경로 기반 규칙이 단순합니다. /drivers/{driverId}/logs/{logId}에 대해 request.auth.uid == driverId(또는 custom claim으로 매핑)일 때만 read/write를 허용합니다. 이는 일반적인 Firestore 모범 사례입니다. - Scalability: 120,000명의 드라이버와 각자 하루 최대 200개의 로그는 하루 최대 24M writes/day를 의미합니다. Firestore는 수평 확장이 가능하며, 많은 서브컬렉션에 쓰기를 분산하면 단일 “hot” 컬렉션 프리픽스 패턴에 쓰기 부하가 집중되는 것을 피할 수 있습니다. 또한 단일 문서에 무한히 커지는 배열을 피해야 합니다. - Efficient queries: 드라이버별 쿼리는 단일 드라이버의 logs 서브컬렉션만 대상으로 하므로 빠르고 비용 효율적입니다. - Cross-driver analytics: 가끔 모든 드라이버의 로그를 가로지르는 쿼리가 필요할 때는 “logs”에 대한 collection group query( collectionGroup('logs') )를 사용해 모든 logs 서브컬렉션을 쿼리할 수 있습니다. 더 무거운 분석의 경우 Firestore에서 대규모 ad-hoc scan을 수행하기보다(extensions 또는 Dataflow를 통해) BigQuery로 export하는 것이 좋습니다. 흔한 오해: A는 더 단순해 보이지만(두 개의 루트 컬렉션), 드라이버별 접근 제어가 더 복잡해집니다(driverId 필드로 필터링해야 함). 또한 문서 ID가 시간 순으로 정렬되는 경우 드라이버 간 쓰기가 hot partition을 만들 수 있습니다. C는 전형적인 anti-pattern입니다. 배열/중첩 리스트는 무한히 커지며 1 MiB 문서 제한과 높은 경합에 걸립니다. D는 자연스러운 계층을 뒤집어 접근 패턴을 복잡하게 만듭니다. 시험 팁: Firestore는 지배적인 쿼리와 보안 경계를 중심으로 모델링하세요. 1:N 관계에는 서브컬렉션을 선호하고, 가끔 필요한 전역 쿼리에는 collection group query를 사용하세요. 큰 배열과, 일상적인 사용자 범위 읽기를 위해 거대한 루트 컬렉션을 스캔해야 하는 설계는 피하세요.

5
문제 5

Your team uses Cloud Build to build a single container image and push it to Artifact Registry with two tags: latest and v2.3.7. You then use Google Cloud Deploy to promote this image through three GKE environments in different regions: dev (us-central1), staging (europe-west1), and prod (asia-northeast1). Compliance requires that the exact same binary is deployed to all three environments over the release week, even if tags are moved or new images are pushed. How should you reference the image in the Cloud Deploy/Skaffold release configuration to guarantee the same image is used across all environments?

latest tag를 사용하는 것은 컴플라이언스 관점에서 안전하지 않습니다. latest는 본질적으로 mutable이며 매 빌드마다 흔히 다른 대상으로 repoint됩니다. 릴리스 주간에 새 image가 push되거나 tag가 이동되면, 서로 다른 환경이 :latest를 참조하면서도 서로 다른 binary를 배포할 수 있습니다. 이는 dev/staging/prod 전반에서 동일한 artifact를 요구하는 조건을 위반하며 auditability와 reproducibility를 약화시킵니다.

환경별로 고유한 image name을 사용하는 것은 naming을 바꾸는 것이지 immutability를 보장하는 것이 아닙니다. api-dev vs api-stg vs api-prod에 대해 서로 다른 image를 실수로 push하거나(또는 tags를 이동시키면) drift가 발생할 수 있습니다. 이 접근은 운영 오버헤드를 증가시키며 동일한 binary가 배포된다는 보장을 제공하지 못합니다. 오히려 환경별 artifact를 조장하여 promote-the-same-release best practices와 충돌합니다.

digest(api@sha256:...)로 image를 pinning하는 것이 immutability를 보장하는 올바른 방법입니다. digest는 image manifest에 대한 content-addressable identifier이며 image의 정확한 bytes를 고유하게 나타냅니다. latest 또는 v2.3.7 같은 tags가 이동되거나 덮어써지더라도, digest 참조는 항상 동일한 artifact로 해석되므로 모든 환경에서 일관된 배포를 보장합니다.

v2.3.7 같은 semantic version tag는 latest보다 안정적이지만, 여전히 tag이므로 retagging/overwriting을 막는 엄격한 통제가 없다면 mutable입니다. 문제에서 “even if tags are moved”라고 명시했으므로, 어떤 tag(semantic version tag 포함)에 의존해서는 동일한 binary를 보장할 수 없습니다. digests가 컴플라이언스에 필요한 기술적 보장을 제공합니다.

문제 분석

핵심 개념: 이 문제는 Artifact Registry + Cloud Deploy(Skaffold 포함)를 사용하는 CI/CD 파이프라인에서의 immutable 배포를 테스트합니다. 핵심 개념은 mutable 참조(tags)와 immutable 참조(digests)의 차이입니다. 환경 전반에 걸쳐 “정확히 동일한 binary”를 요구하는 컴플라이언스 요구사항은 immutable artifact identifier를 배포함으로써 가장 잘 충족됩니다. 정답이 맞는 이유: Container image tag(semantic version 포함)는 시간이 지나면서 다른 image를 가리키도록 변경될 수 있는 포인터입니다. 릴리스 주간 내내 dev, staging, prod가 모두 동일한 image bytes를 실행하도록 보장하려면, content-addressable digest(sha256)로 image를 참조해야 합니다. digest는 image manifest를 고유하게 식별하므로 정확한 image content를 의미합니다. 누군가 latest를 retag하거나 v2.3.7을 덮어쓰거나 새 image를 push하더라도, digest 참조는 항상 동일한 artifact로 해석됩니다. 주요 기능 / Best Practices: - Artifact Registry는 tags와 digests 모두로 image를 저장하며, digests는 immutable identifier입니다. - Cloud Deploy release는 동일한 artifact를 target 간에 promote해야 하며, digest로 pinning하면 promote된 artifact가 drift할 수 없습니다. - Skaffold/Cloud Deploy에서는 rendered manifest가 digest를 사용하도록 image reference를 구성할 수 있습니다(예: build outputs를 통해 또는 digest를 명시적으로 지정). 이는 supply-chain integrity 관행 및 Google Cloud Architecture Framework의 reliability와 security 원칙(반복 가능하고 감사 가능한 배포)과 일치합니다. - digests는 auditability도 향상시킵니다. 로그와 manifest에 배포된 정확한 artifact가 명확히 표시됩니다. 흔한 오해: 많은 사람들이 v2.3.7 같은 semantic version tag가 “관례상” immutable하다고 가정합니다. 실제로는 엄격한 repository policy와 프로세스 통제가 없다면 tags는 mutable입니다. 컴플라이언스 문구는 보통 관례가 아니라 기술적 강제를 요구합니다. 또한 latest는 명시적으로 변경되도록 의도된 것입니다. 시험 팁: “exact same binary”, “immutable”, “reproducible”, “no drift”, “even if tags are moved” 같은 요구사항이 보이면 digest pinning을 선택하세요. tags는 사람이 읽기 쉬운 참조를 위한 것이고, digests는 보장된 identity를 위한 것입니다. 또한 multi-region GKE target은 artifact identity를 바꾸지 않습니다—promotion은 실행 위치와 무관하게 동일한 digest를 참조해야 합니다.

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

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

6
문제 6

Your online ticketing platform runs a payment-validation microservice on a Compute Engine Managed Instance Group (autoscaling between 3 and 10 VMs) behind an internal HTTP(S) Load Balancer; during a canary at 5,000 requests per minute, 1–2% of requests intermittently return HTTP 500 when the code path handling 3-D Secure callbacks is executed, and you need to observe the values of customerId and tokenExpiry at line 214 every time that branch is hit across all running instances over the next 4 hours, with the observations written to Cloud Logging, without modifying code, restarting VMs, or redeploying. Which tool should you use?

Cloud Trace는 distributed tracing, request flow analysis, 그리고 서비스 전반의 latency breakdown에 사용됩니다. 어디에서 시간이 소비되는지 식별하고 느리거나 실패하는 requests를 연관 지을 수는 있지만, 실행 중인 process의 특정 source line에서 임의의 local variables를 동적으로 검사하지는 못합니다. line 214에서 customerId와 tokenExpiry 같은 값을 보려면, Trace는 즉석 debugging 기능이 아니라 사전 애플리케이션 instrumentation이 필요합니다. 따라서 코드 변경 없이 해당 변수를 관찰해야 한다는 요구 사항을 충족하지 못합니다.

Cloud Monitoring은 metrics, dashboards, alerting, uptime checks, 그리고 SLO 기반 observability를 위한 도구입니다. error rates, request volume, 그리고 infrastructure 또는 애플리케이션 metrics를 보여줄 수는 있지만, source code의 특정 line에서 process 내부의 local variables를 캡처하지는 못합니다. logs-based metrics는 기존 logs로부터 파생할 수 있지만, 문제는 애플리케이션을 수정하지 않고 변수 값에 대한 새로운 관찰 결과를 생성해야 한다고 명시합니다. 따라서 이 작업에는 Monitoring이 적절한 도구가 아닙니다.

Cloud Debugger Snapshots는 실행이 선택한 line에 도달했을 때 stack frames와 local variables를 포함한 program state의 특정 시점 view를 캡처합니다. 이는 live debugging 중 상태를 검사하는 데 유용하지만, 다음 4시간 동안 branch가 hit될 때마다 관찰 결과를 Cloud Logging에 기록해야 하는 요구 사항에는 가장 적합하지 않습니다. 문제는 가끔 상태를 캡처하는 것이 아니라 반복적인 logging 동작을 요구합니다. Logpoints는 이러한 반복적이고 log 중심적인 사용 사례를 위해 특별히 설계되었습니다.

Cloud Debugger Logpoints는 실행 중인 애플리케이션의 특정 source line에 logging 동작을 동적으로 추가하도록 설계되었습니다. logpoint가 customerId 및 tokenExpiry와 같은 scope 내 변수를 포함하도록 구성할 수 있으며, 생성된 항목은 중앙에서 검토할 수 있도록 Cloud Logging에 기록됩니다. 이는 문제의 핵심 제약 조건인 코드 수정 없음, VM 재시작 없음, 재배포 없음을 충족합니다. 제시된 옵션 중에서 live production 실행 중 line 단위로 변수를 반복 관찰하고 log output을 남기도록 의도된 유일한 도구입니다.

문제 분석

핵심 개념: 이 문제는 실행 중인 애플리케이션에 대해 production-safe한 동적 instrumentation을 수행하는 것에 관한 것입니다. 요구 사항은 특정 source line이 실행될 때마다 해당 시점에 scope 내에 있는 변수 값을 캡처하고, 그 관찰 결과를 Cloud Logging으로 전송하며, 코드 변경이나 인스턴스 재시작/재배포 없이 이를 수행하는 것입니다. 정답인 이유: 가장 적합한 것은 Cloud Debugger Logpoints입니다. logpoint는 line 214에 배치할 수 있으며, 실행이 해당 line에 도달할 때마다 customerId와 tokenExpiry의 값을 Cloud Logging에 기록하도록 구성할 수 있습니다. 이것은 실행 중인 서비스의 live debugging을 위해 특별히 설계되었으며 코드 수정, VM 재시작, 또는 재배포를 피할 수 있습니다. 주요 기능: - 특정 source line에서 실행 중인 애플리케이션에 대한 동적 instrumentation. - 출력되는 로그 메시지에 local variables와 평가된 expressions를 포함할 수 있음. - 중앙 집중식 분석을 위해 출력을 Cloud Logging에 기록함. - 활성 incident 또는 canary 중 일시적인 관찰에 적합함. 흔한 오해: - Snapshots도 변수를 검사하지만, 일정 시간 동안 hit될 때마다 반복적으로 logging하는 용도보다는 특정 시점의 캡처에 적합합니다. - Cloud Trace와 Cloud Monitoring은 latency, metrics, error trends를 파악하는 데 도움이 되지만, 애플리케이션 instrumentation 없이 특정 source line에서 임의의 local variable을 캡처하지는 못합니다. 시험 팁: 문제에서 코드 변경 없음, 재시작/재배포 없음, 특정 line에서 변수 검사, 그리고 결과를 logs로 전송이라고 하면 Logpoints를 선택하세요. 대신 실행이 특정 line에 도달했을 때 stack frames와 local state를 한 번 캡처하라고 하면 Snapshots를 떠올리세요.

7
문제 7

You operate a Go-based Cloud Functions (2nd gen) HTTP function in us-central1 that processes invoice files at roughly 200 requests per second. The function must read and write objects in a single Cloud Storage bucket named acct-prod-uploads within the same project (retail-prod-123). You must follow the principle of least privilege and avoid project-wide roles and default service accounts. What should you do?

정답. function 전용 user-managed service account에, bucket 수준에서 필요한 Cloud Storage object 권한만 부여하는 것이 최소 권한을 가장 잘 충족합니다. IAM을 acct-prod-uploads로 범위 제한하면 다른 bucket에 대한 접근 권한을 부여하지 않게 됩니다. 또한 function이 이 service account로 실행되도록 구성하면 공유/default identity 대비 감사 가능성이 향상되고 blast radius가 줄어듭니다.

오답. 프로젝트 수준의 roles/storage.admin은 acct-prod-uploads뿐 아니라 프로젝트 내 모든 Cloud Storage 리소스(모든 bucket 포함)에 대한 광범위한 권한을 부여합니다. 이는 최소 권한과 “project-wide roles를 피하라”는 요구사항을 위반합니다. 운영상 단순할 수는 있지만, function이 침해되거나 오동작할 경우 위험이 커집니다.

오답. roles/editor는 매우 높은 권한을 가진 legacy broad role로, Cloud Storage를 훨씬 넘어서는 권한(compute, networking, 일부 맥락에서 IAM 관련 작업 등)을 부여합니다. 이는 최소 권한과 정면으로 충돌하며, 프로덕션에서 흔한 anti-pattern입니다. 또한 문제는 project-wide roles를 피하라고 명시하며, Editor는 일반적으로 project scope를 의미합니다.

오답. default service account 사용은 default service accounts를 피하라는 요구사항에 위배됩니다. default identity는 종종 공유되며 필요 이상으로 넓은 권한을 가질 수 있어 최소 권한을 강제하기 어렵고 blast radius를 증가시킵니다. 모범 사례는 workload별 전용 user-managed service account를 사용하고 권한 범위를 좁게 제한하는 것입니다.

문제 분석

핵심 개념: 이 문제는 Cloud Functions (2nd gen)이 Cloud Storage에 접근할 때의 IAM 설계를 평가하며, 최소 권한(least privilege), 리소스 수준 권한(resource-level permissions), 그리고 default service accounts 회피를 강조합니다. Cloud Functions (2nd gen)은 Cloud Run 인프라에서 실행되며, 전용 runtime service account를 구성할 수 있습니다. 정답이 맞는 이유: 옵션 A는 user-managed service account (UMSA)를 생성하고, 특정 bucket(acct-prod-uploads)에 범위를 제한한 필요한 Cloud Storage object 권한만 부여한 뒤, 해당 UMSA로 function이 실행되도록 구성합니다. 이는 Google Cloud Architecture Framework의 security pillar에 부합합니다: blast radius 최소화, 최소 권한 적용, 프로젝트 전체 역할(project-wide roles)보다 리소스 수준 IAM binding을 선호. function이 한 bucket에서만 object read/write가 필요하므로, bucket-level IAM이 올바른 범위입니다. 주요 기능 / 구성: - UMSA 생성(예: cf-invoice-processor@retail-prod-123.iam.gserviceaccount.com). - bucket에 대해서만 최소 권한 부여. 실무에서는 roles/storage.objectViewer + roles/storage.objectCreator(또는 update/delete가 필요하면 roles/storage.objectAdmin) 같은 predefined roles를 자주 사용합니다. 권한을 매우 정밀하게 제어해야 한다면 custom role도 허용됩니다(예: 필요에 따라 storage.objects.get, storage.objects.create, storage.objects.list만). - role을 project가 아니라 bucket 수준에 binding: gs://acct-prod-uploads IAM policy. - Cloud Functions (2nd gen)을 --service-account로 배포하여 UMSA로 실행. 흔한 오해: - “프로젝트 수준에서 Storage Admin이면 storage니까 괜찮다.” 이는 최소 권한을 위반하며 프로젝트 내 모든 bucket으로 접근 범위를 확장합니다. - “Editor가 편하다.” Editor는 과도하게 광범위하며 관련 없는 많은 권한을 포함합니다. - “default service accounts는 Google이 관리하니 안전하다.” default SA는 종종 광범위한 권한을 가지며 여러 workload에서 공유되어 blast radius를 키우고 감사(auditing)를 어렵게 만듭니다. 시험 팁: - GCP에서 workload identity는 workload별 전용 UMSA를 선호하고, 요구사항을 만족하는 가장 좁은 리소스(bucket/dataset/topic)로 IAM 범위를 제한하세요. - Cloud Functions (2nd gen)은 runtime service account 지정이 가능하며, 플랫폼이 사용하는 service agent와 혼동하지 마세요. - 문제에서 “project-wide roles와 default service accounts를 피하라”고 명시하면, 보통: custom 또는 최소 predefined roles + resource-level binding + UMSA를 기대하면 됩니다.

8
문제 8

You are developing a local analytics worker that aggregates readings from 50 factory sensors at 10 Hz and publishes normalized events to a Pub/Sub topic named telemetry-normalized; you build locally 8–10 times per day and need each build to validate Pub/Sub integration in under 2 minutes without internet access or incurring any Google Cloud charges, using a dev project ID of plant-dev-31415—how should you configure local testing?

Cloud Code는 개발 워크플로를 지원할 수 있지만, 이 선택지는 여전히 애플리케이션을 실제 관리형 Pub/Sub 서비스인 pubsub.googleapis.com으로 연결합니다. 이는 인터넷 연결, 유효한 credential, 그리고 Google Cloud project에서의 API 활성화를 요구합니다. 또한 비용이 발생할 수 있고 외부 의존성으로 인한 지연 시간을 초래하므로, 오프라인에서 2분 이내 로컬 검증이라는 요구 사항과 충돌합니다. 따라서 이 시나리오의 핵심 제약 조건을 충족하지 못합니다.

이 선택지는 Pub/Sub emulator를 사용하며, 이는 인터넷 액세스나 Google Cloud 과금 없이 로컬 Pub/Sub 통합 테스트를 수행하기 위한 올바른 도구입니다. project ID plant-dev-31415로 emulator를 시작하면 로컬 테스트 환경이 애플리케이션이 기대하는 project 구성과 일치하게 되며, 이는 리소스 이름이 project 컨텍스트를 기반으로 생성될 때 유용합니다. env-init 명령은 client library가 emulator에 자동으로 연결하도록 필요한 environment variable을 export하는 표준 문서화 방식입니다. 이는 빠르고 반복 가능한 로컬 검증을 제공하며, 문제에서 제시한 모든 제약 조건을 충족합니다.

이 선택지는 로컬 emulator가 아니라 production Pub/Sub endpoint를 사용하므로 인터넷 액세스 없이 동작할 수 없습니다. project에서 Pub/Sub API를 활성화하는 것은 emulator를 사용할 때가 아니라 실제 서비스를 호출할 때만 관련이 있습니다. 또한 과금 대상 사용이 발생할 위험이 있고, 메모리 내 로컬 emulator와 비교해 로컬 반복 작업도 느려집니다. 결과적으로 오프라인 및 무비용 테스트라는 명시적 요구 사항을 충족하지 못합니다.

이 선택지는 부분적으로는 맞습니다. PUBSUB_EMULATOR_HOST를 설정하는 것은 실제로 많은 client library가 로컬 emulator endpoint를 찾는 방식이기 때문입니다. 그러나 어떤 project ID 문자열이든 괜찮다고 말하는데, 시나리오에서는 명시적으로 dev project ID를 제공하고 로컬 테스트를 어떻게 구성할지 묻고 있으므로, 해당 project ID로 문서화된 방식대로 emulator를 시작하는 것이 더 적절합니다. 또한 emulator 사용을 위해 로컬 환경을 구성하는 표준 gcloud 지원 방식인 env-init 단계도 빠져 있습니다. B가 더 완전하고 문제의 요구와 더 잘 부합하므로, D는 최선의 답이 아닙니다.

문제 분석

핵심 개념: 이 문제는 Pub/Sub에 대한 오프라인, 무비용 로컬 통합 테스트에 관한 것이며, 이는 정확히 Pub/Sub emulator가 설계된 목적입니다. 정답인 이유: 올바른 구성은 Pub/Sub emulator를 로컬에 설치하고 실행한 다음, 애플리케이션이 실제 Pub/Sub 서비스 대신 해당 emulator를 대상으로 하도록 구성하는 것입니다. 주요 특징: emulator는 개발자 머신에서 완전히 실행되며, 인터넷 액세스와 과금을 피하고, 원하는 project ID로 초기화할 수 있어 로컬 리소스가 애플리케이션 구성과 일관되게 네임스페이스화됩니다. 흔한 오해: emulator 기반 테스트에는 실제 Pub/Sub API를 활성화하거나 pubsub.googleapis.com을 호출할 필요가 없으며, emulator를 사용하는 것도 여전히 클라이언트 동작에 대한 유효한 통합 테스트입니다. 시험 팁: 문제가 인터넷 없음, 비용 없음, 빠른 로컬 검증을 강조하면, production endpoint를 사용하는 선택지보다 문서화된 gcloud 워크플로를 따르는 emulator 기반 선택지를 우선 고르세요.

9
문제 9

You are the lead developer for a real-time fleet tracking service running on Cloud Run at a transportation company with strict uptime SLAs. Binary Authorization for Cloud Run is enforced as an organization policy with a single attestor, and all service images are normally attested through the CI/CD pipeline. Deployments are allowed only during a 45-minute change window starting at 02:15 local time. A zero-day vulnerability in a widely used library is being actively exploited, and you must deploy a patched image immediately, before the next change window. You have built the new image and received written approval from your director via the company ticketing system. What should you do?

이미지를 exempt image patterns에 추가하면 policy에 우회 경로가 생기며, 이는 사고 이후에도 지속될 수 있습니다. 특정 이미지 이름으로 범위를 제한하더라도 통제 모델을 약화시키고 장기적 위험을 증가시킵니다(향후 이미지가 패턴과 매칭될 수 있거나, 예외가 재사용될 수 있음). 이는 일반적으로 최소 권한과 공급망 보안을 위한 좋은 거버넌스에 반합니다.

개인 private key로 서명하고 attestor의 public key를 변경하는 것은 신뢰 모델을 훼손합니다. attestor는 강력한 키 관리, rotation, 그리고 역할 분리(separation of duties)를 갖춘 보안/CI 시스템에 의해 통제되어야 합니다. attestor가 개인 개발자 키를 신뢰하도록 업데이트하는 것은 위험하고 감사가 어렵으며, 의도된 CI/CD 검증 프로세스를 우회하는 선례를 만들 수 있습니다.

organization-level Binary Authorization policy를 일시적으로 비활성화하는 것은 범위가 지나치게 넓고 위험이 큽니다. 긴급 서비스뿐 아니라 적용 대상인 모든 리소스에 대한 강제 적용이 제거되어, 해당 기간 동안 실수 또는 악의적인 미검증 배포 가능성이 증가합니다. 또한 통제되고 변경이 최소화된 절차와 감사 가능성이 필수인 엄격한 uptime/SLA 환경과도 충돌합니다.

breakglass 접근은 보안 거버넌스를 유지하면서 긴급하고 예외적인 배포를 위해 설계되었습니다. 일반적으로 문서화된 정당화(티켓/승인), 엄격한 범위 제한(특정 서비스/이미지), 시간 제한 통제, 그리고 완전한 감사 로깅을 포함합니다. 이는 현재 악용 중인 zero-day에 대해 즉시 배포해야 하는 요구를 충족하면서, Binary Authorization을 영구적으로 약화시키거나 org-wide 보호를 비활성화하지 않습니다.

문제 분석

핵심 개념: 이 문제는 Cloud Run에 대한 Binary Authorization(BinAuthz) 강제 적용과 엄격한 거버넌스 하에서 긴급 배포를 처리하는 방법을 평가합니다. BinAuthz는 이미지에 필요한 attestation이 없으면 배포를 차단하는 공급망(supply-chain) 제어입니다. Cloud Run의 경우 강제 적용은 보통 organization policy를 통해 적용되며, attestation은 신뢰할 수 있는 CI/CD 프로세스에 의해 생성됩니다. 정답이 맞는 이유: “breakglass” 접근은 정상적인 통제(변경 윈도우, 표준 CI/CD attestation 흐름)를 따를 수 없는 예외 상황(예: 현재 악용 중인 zero-day)에서 의도된, 감사 가능한 메커니즘입니다. Breakglass는 통제를 전반적으로 약화시키는 대신, 명시적이고 문서화된 정당화와 보통 범위가 매우 제한되고 시간 제한이 있는 예외를 요구함으로써 보안 거버넌스를 유지합니다. 이미 director의 서면 승인이 있으므로 필요한 정당화와 감사 추적을 뒷받침합니다. 이는 Google Cloud Architecture Framework의 보안, 거버넌스, 운영 우수성 원칙(통제 유지, blast radius 최소화, 추적성 보장)과 일치합니다. 주요 기능 / 모범 사례: - 사전에 정의되어 있고, 로깅되며, 되돌릴 수 있는(시간 제한 예외 또는 긴급 attestation 프로세스) 긴급 배포 경로를 사용합니다. - 예외를 가능한 한 좁게(단일 서비스/이미지, 최단 기간) 유지하고 티켓/승인 참조를 기록합니다. - 배포 후에는 정상 상태로 복구하고, 필요하다면 표준 파이프라인을 통해 패치된 이미지를 사후적으로(retroactively) 적절히 attestation 처리합니다. 흔한 오해: - “그냥 policy를 비활성화”하는 것이 가장 빠르게 보이지만, 모든 서비스에 대한 보호를 제거하고 컴플라이언스를 훼손합니다. - “exempt patterns를 추가”하는 것은 표적화된 것처럼 보이지만, 나중에 악용될 수 있는 영구적인 우회를 만듭니다. - “개인 키를 사용”하는 것은 개인 서명과 조직 신뢰를 혼동한 것입니다. attestor는 임시(ad-hoc) 개발자 키가 아니라, 통제되고 관리되는 신뢰 루트(trust roots)를 나타냅니다. 시험 팁: org-level BinAuthz 강제 적용과 긴급 보안 수정이 함께 보이면, 거버넌스를 유지하는 선택지(최소 권한, 감사 가능한 예외, 최소 범위/시간)를 고르세요. 광범위한 비활성화나 영구적인 우회는 피하세요. “breakglass,” “documented justification,” “emergency procedure” 같은 표현을 찾으면, 규제 환경에서의 올바른 운영 패턴을 시사합니다.

10
문제 10

Your company is building a serverless QR-code rendering API on Cloud Run to generate boarding passes. The API must read PDF templates stored in a private Cloud Storage bucket named tickets-secure-prod in europe-west1, and the security team requires that: (1) production buckets must never be publicly accessible, (2) production workloads must not run with default service accounts, and (3) the API needs only read access to objects; peak traffic is 250 requests per second and clients will never access the bucket directly. You need to grant the API permission to read the templates while following Google-recommended best practices and the security constraints; what should you do?

클라이언트가 bucket에 접근하지 않으므로 signed URL은 불필요하며, Cloud Run 서비스는 IAM을 사용해 직접 읽을 수 있습니다. 또한 Compute Engine default service account에 권한을 부여하는 것은 프로덕션 워크로드가 default service account로 실행되면 안 된다는 요구사항을 위반합니다. signed URL은 이 시나리오의 서버 측 접근 패턴을 개선하지 않으면서 운영 오버헤드(키 로테이션, URL 생성)도 추가합니다.

Public Access Prevention으로 bucket이 public이 될 수 없게 하는 것은 맞지만, 이 옵션은 여전히 Compute Engine default service account에 접근 권한을 부여하므로 프로덕션 워크로드가 default service account로 실행되면 안 된다는 명시적 제약을 위반합니다. Cloud Run은 최소 권한과 더 나은 감사 가능성을 위해 전용 user-managed service account를 사용해야 합니다.

user-managed service account를 사용하고 roles/storage.objectViewer를 부여하는 것은 맞지만, signed URL을 강제하는 것은 이 시나리오에서 모범 사례가 아닙니다. signed URL은 외부 클라이언트에 임시 접근을 위임하기 위한 것이며, 여기서는 Cloud Run 서비스만 접근하면 됩니다. “절대 공개적으로 접근 가능하면 안 됨”에 대한 더 강력한 제어는 signed URL이 아니라 Public Access Prevention입니다.

이 선택지는 모든 제약과 모범 사례를 충족합니다: Public Access Prevention은 프로덕션 bucket이 public으로 설정될 수 없도록 보장하여 보안 요구사항을 만족합니다. Cloud Run이 user-managed service account를 사용하도록 구성하면 default service account 사용을 피할 수 있습니다. 해당 service account에 bucket에 대한 roles/storage.objectViewer를 부여하면 API가 서버 측에서 템플릿을 가져오는 데 필요한 최소 권한의 read-only access를 제공합니다.

문제 분석

핵심 개념: 이 문제는 Google Cloud Architecture Framework의 security pillar에 맞춰, IAM, 최소 권한, 그리고 하드닝 제어(Public Access Prevention)를 사용하여 Cloud Run에서 Cloud Storage로의 안전한 서비스 간 접근을 테스트합니다. 정답이 맞는 이유: API는 Cloud Run에서 실행되며 프로덕션 bucket에 있는 비공개 PDF 템플릿을 읽어야 합니다. 클라이언트는 bucket에 직접 접근하지 않으므로 signed URL이 아니라 IAM을 통한 직접 서버 측 접근을 사용해야 합니다. 보안 팀은 프로덕션 bucket이 절대 공개적으로 접근 가능하면 안 된다고 요구하며, 이는 Cloud Storage Public Access Prevention(PAP)으로 가장 잘 강제할 수 있습니다. PAP는 bucket 수준에서 모든 public IAM binding(allUsers/allAuthenticatedUsers)을 차단하여, 나중에 누군가 실수로 public access를 부여하려 해도 우발적 노출을 방지합니다. 워크로드는 default service account로 실행되면 안 됩니다. Cloud Run 서비스는 전용 user-managed service account(최소 권한, 명확한 소유권, 더 쉬운 감사)를 사용해야 합니다. 그런 다음 해당 service account에 필요한 권한만 부여합니다: 특정 bucket에 roles/storage.objectViewer(또는 적용 가능하다면 IAM Conditions/프리픽스를 통해 더 좁게). 이는 “객체에 대한 read-only access”를 충족하고 과도한 권한 부여를 피합니다. 주요 기능/구성: - Cloud Storage: tickets-secure-prod에서 Public Access Prevention을 활성화하여 public으로 만들 수 없도록 보장합니다. - Cloud Run: 서비스를 user-managed service account(Compute Engine default 또는 App Engine/Cloud Run default service identity가 아님)로 실행하도록 구성합니다. - IAM: 해당 service account에 bucket 수준으로 roles/storage.objectViewer를 부여합니다. - 리전 참고: europe-west1의 bucket은 문제없으며, Cloud Run을 europe-west1에 배포하면 latency/egress를 최소화할 수 있습니다. 250 RPS는 Cloud Run autoscaling으로 처리되며, Storage read throughput도 일반적으로 충분합니다. 또한 인스턴스별로 템플릿을 메모리에 캐싱하면 반복 읽기를 줄일 수 있습니다. 흔한 오해: Signed URL은 “private bucket access”에 자주 제안되지만, 주로 IAM 없이 클라이언트에 임시 접근을 위임하기 위한 것입니다. 여기서는 클라이언트가 bucket에 접근하지 않으므로 signed URL은 복잡성과 키 관리만 추가하며, PAP만큼 “no public access” 요구사항을 직접적으로 충족하지도 못합니다. 시험 팁: “프로덕션 bucket은 절대 public이면 안 됨”을 보면 Public Access Prevention을 떠올리세요. “default service account를 쓰지 말라”를 보면 워크로드별 user-managed service account를 떠올리세요. “read access만 필요”라면 요구사항을 만족하는 가장 좁은 리소스 범위(bucket/object prefix)에서 roles/storage.objectViewer를 선택하세요.

합격 후기(6)

V
V***********Nov 24, 2025

학습 기간: 2 months

The scenarios in this app were extremely useful. The explanations made even the tricky deployment questions easy to understand. Definitely worth using.

B
B************Nov 21, 2025

학습 기간: 2 months

The questions weren’t just easy recalls — they taught me how to approach real developer scenarios. I passed this week thanks to these practice sets.

철
철**Nov 17, 2025

학습 기간: 1 month

1개월 구독하니 빠르게 풀어야 한다는 강박이 생기면서 더 열심히 공부하게 됐던거 같아요. 다행히 문제들이 비슷해서 쉽게 풀 수 있었네요

이
이**Nov 15, 2025

학습 기간: 1 month

이 앱의 문제들과 실제 시험 문제들이 많이 비슷해서 쉽게 풀었어요! 첫 시험만에 합격하니 좋네요 굿굿

R
R***********Nov 6, 2025

학습 기간: 1 month

I prepared for three weeks using Cloud Pass and the improvement was huge. The difficulty level was close to the real Cloud Developer exam, and the explanations helped me fill in my knowledge gaps quickly.

다른 모의고사

Practice Test #1

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

Practice Test #2

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

Practice Test #3

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

지금 학습 시작하기

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

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