Google Cloud Certified - Professional Cloud Architect 합격

2024.12.27 Google Cloud PCA 합격.

 

시험에 앞서, 2-3일 공부를 했다. 그리고 합격했다. 

GCP 베이스가 있다면, 3일 공부로 합격이 가능하다. 공부 효율, 효과 있는 공부 방법, 집중도에 따라 달라지겠지만, 가능했다. 

 

몇 달 전 PSE 공부한 내용이나 흐름이 기억에 많이 남아,

PCA는 더미 문제를 2-3일 이해를 해가면서 보는 것으로 합격했다.

더미 문제의 이해하며 풀기(또는 정독하기)는 가장 짧고 굵은 시험 준비 방법이다.

 * 풀지 않고, 한 문항씩 답안와 해석을 보며 스터디하는 것은 거의 같은 효과를 갖는다. 집중력을 놓치지 않는다면, 더 효과 있고 효율적이다.

 

재언하면,

가장 효과적인 단기 공부법: '더미 문제(또는 기출문제)' 활용하기

시간이 절대적으로 부족한 상황에서 방대한 양의 이론서를 처음부터 끝까지 정독하는 것은 비효율적이다. 이럴 때 가장 강력한 무기는 바로 '더미 문제(Dump Questions)' 즉, 기출문제나 예상 문제 모음이다.

핵심은 단순히 문제를 풀고 정답을 맞히는 것에 그치지 않고, 각 문제를 깊이 있게 이해하며 분석하는 것이다.

• 1단계: 문제와 답 함께 보기: 문제를 풀려고 애쓰기보다, 문제와 정답, 그리고 해설을 함께 놓고 마치 스터디하듯 정독한다. 이 과정은 시간과 에너지를 아끼면서 시험의 출제 경향과 핵심 개념을 빠르게 파악하는 데 매우 효과적이다.
• 2단계: '왜'라는 질문 던지기: "왜 이 선택지가 정답일까?", "다른 선택지들은 왜 틀렸을까?"를 스스로에게 계속 질문하며 파고들어야 한다. 이 과정에서 GCP 서비스 간의 관계와 특정 상황에 어떤 솔루션이 최적인지를 자연스럽게 익히게 된다.
• 3단계: 개념 확장하기: 특정 서비스(예: Cloud Storage)에 대한 문제가 나왔다면, 그 서비스의 다양한 클래스(Standard, Nearline, Coldline, Archive) 특징과 비용 구조까지 연관 지어 학습하는 방식으로 지식을 확장한다.

이처럼 더미 문제를 단순한 '암기'의 도구가 아닌, '이해'를 위한 학습 자료로 활용한다면, 2-3일이라는 짧은 시간 동안에도 합격에 필요한 지식을 압축적으로 습득할 수 있다. 집중력만 유지한다면, 이는 강의를 듣는 것보다 훨씬 효율적인 방법이 될 수 있다.

 

PCA 정리. Worth reviewing! 

번호	핵심 개념	설명
1	디스크 이미지 생성 및 배포	프로덕션 환경과 동일한 가상 머신 복사본을 다른 리전에 배포할 때는 디스크 스냅샷을 생성하고, 이 스냅샷을 기반으로 이미지를 생성하여 새 인스턴스에 배포하는 것이 효율적입니다. 이를 통해 운영 중인 시스템의 변경 사항을 쉽게 반영하고 관리할 수 있습니다.
2	Anthos Service Mesh와 SLO	Anthos Service Mesh를 사용하면 **서비스 수준 목표(SLO)**를 정의하고 모니터링 할 수 있습니다. 이를 통해 요청 지연 시간과 같은 주요 성능 지표가 특정 임계값을 초과할 경우 알림을 받아 신속하게 대응할 수 있습니다.
3	로그 보안 및 이상 탐지	보안 로그는 Pub/Sub으로 실시간 스트리밍하고, Cloud Functions을 트리거하여 이상 징후를 즉시 탐지하는 것이 Google 권장 사례입니다. 이를 통해 비정상적인 방화벽 변경이나 서버 침입과 같은 보안 위협에 신속하게 대응할 수 있습니다.
4	Identity-Aware Proxy (IAP)	IAP는 VPN 없이 SSH 또는 RDP를 통해 Compute Engine 인스턴스에 안전하게 연결할 수 있는 Google Cloud 서비스입니다. 보안 요구 사항을 충족하면서 편리하게 인스턴스에 접근할 수 있습니다.
5	폴더 수준의 IAM 권한 관리	조직 내 특정 폴더에 대한 프로젝트 생성 권한을 제어하려면, 폴더 수준에서 IAM 역할을 할당해야 합니다. 이를 통해 개발팀이 특정 폴더(예: Finance)에서 프로젝트를 생성하는 것을 방지할 수 있습니다.
6	Sole-tenant Node와 Node Affinity	Sole-tenant Node는 특정 고객의 워크로드만 실행되는 단일 테넌트 노드입니다. Node Affinity Labels를 사용하면 워크로드를 특정 노드 또는 노드 그룹에 할당하여 고객별 데이터 격리 요구 사항을 충족할 수 있습니다.
7	Istio Fault Injection	Istio의 Fault Injection 기능을 사용하여 마이크로서비스의 장애 상황을 시뮬레이션하고 애플리케이션의 복원력을 테스트할 수 있습니다. 이를 통해 실제 장애 발생 시 애플리케이션의 동작을 검증하고 개선할 수 있습니다.
8	부하 테스트 (Load Testing)	애플리케이션의 성능과 안정성을 검증하기 위해 부하 테스트 도구를 사용하여 예상 사용자 트래픽을 시뮬레이션하고, 애플리케이션의 응답 시간, 처리량, 지연 시간 등을 측정해야 합니다.
9	글로벌 HTTP(S) 로드 밸런서와 Kubemci	전 세계 사용자에게 낮은 지연 시간으로 서비스를 제공하려면, 여러 리전에 GKE 클러스터를 배포하고 Kubemci를 사용하여 글로벌 HTTP(S) 로드 밸런서를 구성하는 것이 좋습니다.
10	Cloud NAT	Cloud NAT를 사용하면 공용 IP 주소가 없는 GKE 클러스터의 인스턴스가 인터넷에 안전하게 액세스할 수 있습니다. 이를 통해 보안 요구 사항을 충족하면서 외부 서비스와의 통신이 가능합니다.
11	Rightsizing Recommendations	Google Cloud의 Rightsizing Recommendations는 애플리케이션의 CPU 및 메모리 사용량을 분석하여 최적의 리소스 구성을 제안합니다. 이를 통해 비용을 절감하고 성능을 개선할 수 있습니다.
12	HTTP(S) 부하 분산기와 세션 지속성	Google Cloud의 HTTP(S) 부하 분산기는 웹소켓과 상태 유지형 HTTP 세션을 지원합니다. **세션 지속성(Session Affinity)**을 구성하면 동일한 사용자의 요청을 동일한 백엔드 서버로 라우팅하여 애플리케이션의 안정성을 보장할 수 있습니다.
13	Google Cloud Activity 페이지	GCP 프로젝트 내에서 수행된 작업을 추적하려면 Activity 페이지를 사용하는 것이 가장 효과적입니다. Data Access 카테고리를 통해 VM 생성과 같은 작업을 수행한 사용자와 작업 시간을 확인할 수 있습니다.
14	Local SSD와 Cloud Storage 백업	Local SSD는 빠른 쓰기 성능을 제공하여 백업 시간과 디스크 성능에 미치는 영향을 최소화합니다. 백업 완료 후 gsutil을 사용하여 데이터를 Cloud Storage로 전송하여 안정성을 확보합니다.
15	부하 테스트 요구사항	효과적인 부하 테스트를 위해서는 부하 테스트 환경을 별도의 프로젝트로 분리하고, 상세한 로깅 및 메트릭 수집을 통해 성능 병목 현상을 파악해야 합니다. 또한, 타사 시스템의 부하 처리 능력도 함께 고려해야 합니다.
16	App Engine과 Cloud Datastore	App Engine은 서버리스 컴퓨팅 플랫폼으로, 트래픽 변동에 따라 자동으로 확장됩니다. Cloud Datastore는 NoSQL 문서 데이터베이스로, 유연한 스키마와 자동 확장을 제공합니다. 이 둘의 조합은 가변적인 트래픽을 처리하는 웹 애플리케이션에 적합합니다.
17	Cloud Storage에 로그 저장	대용량 로그 데이터를 안정적이고 비용 효율적으로 저장하려면 Cloud Storage를 사용하는 것이 가장 적합합니다. 메타데이터를 파일 내용에 추가하고, 파일을 압축하여 저장 용량을 최적화하고, 파일 이름을 서버 이름과 타임스탬프로 지정하여 쉽게 검색할 수 있도록 합니다.
18	CI/CD 파이프라인 보안	CI/CD 파이프라인에 소스 코드 보안 분석기와 취약점 보안 스캐너를 통합하면 보안 오류를 조기에 발견하고 예방할 수 있습니다. 이를 통해 릴리스 속도를 유지하면서 보안을 강화할 수 있습니다.
19	Compute Engine Managed Instance Groups와 Auto-scaling	Compute Engine Managed Instance Groups는 자동 확장(auto-scaling) 기능을 제공하여 테스트 부하에 따라 인스턴스 수를 동적으로 조정합니다. 이를 통해 테스트 시간을 단축하고 비용을 최적화할 수 있습니다.
20	디지털 서명 (Digital Signature)	로그 데이터의 무결성과 진위성을 보장하기 위해 디지털 서명을 사용할 수 있습니다. 각 로그 항목과 타임스탬프에 디지털 서명을 추가하면 로그 데이터가 변경되지 않았음을 증명할 수 있습니다.
21	No-Ops와 Auto-Scaling	**Google Kubernetes Engine (GKE)**과 App Engine Standard Environment는 운영 부담을 최소화하는 No-Ops와 자동 확장을 지원하여, 인프라 관리보다 애플리케이션 개발에 더 집중할 수 있도록 돕습니다.
22	Serverless VPC Access	Serverless VPC Access를 사용하면 App Engine Standard와 같은 서버리스 환경에서 VPC 네트워크에 있는 리소스(예: 온프레미스 데이터베이스)에 안전하게 연결할 수 있습니다.
23	App Engine Standard Environment	App Engine Standard Environment는 예측 불가능한 워크로드를 가진 HTTP(S) API에 적합하며, 자동 확장 및 로드 밸런싱을 통해 안정성을 보장하고 운영 오버헤드를 최소화합니다.
24	gsutil hash와 CRC32C 해시	gsutil hash 명령어를 사용하여 온프레미스 파일의 CRC32C 해시를 생성하고, gsutil ls -L 명령어로 Cloud Storage에 업로드된 파일의 CRC32C 해시를 확인하여 파일 무결성을 검증할 수 있습니다.
25	API 버전 관리	이전 버전과 호환되지 않는 API 변경 시, 버전 번호를 증가시키는 전략을 사용하면 고객에게 안정성을 제공하고 변경 이력을 명확하게 관리할 수 있습니다.
26	Data Transfer Appliance	대규모 온프레미스 데이터를 Cloud Storage로 마이그레이션할 때, Data Transfer Appliance를 사용하면 네트워크 대역폭의 제한을 받지 않고 빠르고 안전하게 데이터를 전송할 수 있습니다.
27	Regional SSD Persistent Disk	Regional SSD Persistent Disk는 두 개의 존에 걸쳐 실시간 데이터 복제를 제공하여 고가용성을 보장합니다. Force-attach 기능을 통해 장애 발생 시 빠르게 다른 인스턴스에 연결하여 다운타임을 최소화할 수 있습니다.
28	조직 뷰어(Org Viewer)와 프로젝트 뷰어(Project Viewer)	보안팀에 **조직 뷰어(Org Viewer)**와 프로젝트 뷰어(Project Viewer) 역할을 부여하면 조직 내 모든 프로젝트에 대한 가시성을 확보하면서도 변경 권한은 제한할 수 있습니다.
29	Cloud Storage와 데이터 레이크	Cloud Storage는 비정형 데이터를 원본 그대로 저장하기에 적합하며, 데이터 레이크의 기반 스토리지로 활용될 수 있습니다. 데이터 처리 파이프라인은 Cloud Storage에서 데이터를 읽어 처리하도록 설계해야 합니다.
30	Kubernetes 자동 확장과 Pub/Sub 메트릭	subscription/num_undelivered_messages 메트릭을 기반으로 Kubernetes 자동 확장을 구성하면 Pub/Sub에서 메시지를 처리하는 애플리케이션의 처리량을 동적으로 조정할 수 있습니다.
31	고객 제공 암호화 키 (Customer-Supplied Encryption Keys, CSEK)	**고객 제공 암호화 키 (CSEK)**를 사용하면 Google Cloud 외부에서 생성한 암호화 키를 사용하여 BigQuery 데이터를 암호화할 수 있습니다. 이를 통해 데이터 보안을 강화하고 규정 준수 요구 사항을 충족할 수 있습니다.
32	Cloud Functions, Cloud Storage, Firestore	Cloud Functions는 트래픽에 따라 자동 확장되는 서버리스 컴퓨팅 서비스로, API 호스팅에 적합합니다. Cloud Storage는 정적 콘텐츠를 저장하고, Firestore는 사용자 데이터를 저장하는 데 사용될 수 있습니다. 이 조합은 비용 효율적이고 확장 가능한 웹 애플리케이션을 구축하는 데 유용합니다.
33	VPC Service Controls와 Private Google Access	VPC Service Controls는 데이터 유출을 방지하기 위한 보안 경계를 생성합니다. Private Google Access는 온프레미스 환경에서 Google API에 비공개로 액세스할 수 있도록 합니다. 이 둘을 함께 구성하면 BigQuery와 같은 Google Cloud 리소스에 대한 보안을 강화할 수 있습니다.
34	Cloud KMS와 CMEK	Cloud KMS를 사용하여 암호화 키를 생성하고, **Cloud Storage 버킷의 기본 암호화 키로 설정(CMEK)**하면 버킷에 저장되는 모든 객체가 자동으로 암호화됩니다. 또한, Cloud KMS를 통해 키 회전을 자동화하여 보안을 강화할 수 있습니다.
35	gcloud alpha container clusters update	gcloud alpha container clusters update 명령어에 --enable-autoscaling, --min-nodes, --max-nodes 옵션을 사용하면 실행 중인 GKE 클러스터의 자동 확장을 활성화하고 최소/최대 노드 수를 설정할 수 있습니다.
36	컨테이너 태그와 커밋 해시	컨테이너 태그를 소스 코드 커밋 해시와 일치시키면 배포된 애플리케이션의 정확한 소스 코드 버전을 추적할 수 있어, 감사 및 디버깅이 용이해집니다.
37	Cloud CDN과 Managed Instance Group	Cloud CDN은 Cloud Storage에 저장된 콘텐츠를 캐싱하여 사용자에게 빠르게 전달합니다. Managed Instance Group은 애플리케이션의 가용성과 확장성을 높입니다. Global Load Balancer는 트래픽을 Managed Instance Group과 Cloud Storage 버킷으로 분산하여 성능과 안정성을 향상시킵니다.
38	App Engine	App Engine은 서버리스 플랫폼으로, 인프라 관리에 대한 부담 없이 애플리케이션을 배포하고 확장할 수 있습니다. 수백만 명의 동시 사용자를 지원할 수 있는 확장성을 제공하며, 개발자는 코드 작성에만 집중할 수 있습니다.
39	Dataflow와 Cloud DLP API	Dataflow 파이프라인에서 Cloud DLP API를 사용하여 PII 데이터를 제거하면, PII 데이터를 저장하지 않고도 데이터를 안전하게 처리하고 BigQuery에 저장할 수 있습니다.
40	Binary Authorization	Binary Authorization을 사용하면 승인된 Docker 이미지만 GKE 클러스터에 배포되도록 강제할 수 있습니다. 이를 통해 개발, 스테이징, 프로덕션 환경 간의 배포 프로세스를 제어하고 보안을 강화할 수 있습니다.
41	Cloud Logging과 Cloud Storage	Cloud Logging에서 필터를 설정하고 Cloud Storage 버킷을 로그 싱크로 지정하면, 특정 로그(예: Cloud VPN 로그)를 장기간 보관할 수 있습니다. 이를 통해 운영팀은 Cloud VPN 로그 이벤트를 1년 동안 저장할 수 있습니다.
42	BigQuery 뷰와 IAM	BigQuery 뷰를 사용하면 기본 테이블에 대한 직접적인 액세스 권한 없이 데이터의 하위 집합을 공유할 수 있습니다. IAM 역할을 사용하여 데이터 세트에 대한 액세스 권한을 부여하면 PII와 같은 민감한 데이터를 보호하면서 데이터 과학 팀에 필요한 데이터만 제공할 수 있습니다.
43	Cloud Logging Agent, Cloud Storage, Object Lifecycle, Bucket Lock	Cloud Logging Agent를 사용하여 Compute Engine 인스턴스에서 로그를 수집하고, Cloud Storage로 로그를 내보내기(sink) 합니다. Object Lifecycle 규칙을 사용하여 Regional Storage에서 Coldline Storage로 자동 이동시켜 비용을 절감하고, Bucket Lock을 사용하여 최소 보존 기간(2년)을 설정하여 규정 준수 요구 사항을 충족합니다.
44	마이크로서비스와 완전 관리형 서비스	마이크로서비스 아키텍처와 완전 관리형 서비스를 사용하면 인프라와 애플리케이션을 분리하고, 개발 및 릴리스 속도를 향상시키고, 유연한 확장성을 확보하고, CI/CD 파이프라인 관리를 개선하고, A/B 테스트를 용이하게 수행할 수 있습니다.
45	Cloud Bigtable RowKey 전략	Cloud Bigtable의 RowKey를 신중하게 설계하면 핫스팟 문제를 방지하고 쿼리 성능을 향상시킬 수 있습니다. RowKey는 데이터를 여러 노드에 고르게 분산시키도록 설계해야 합니다.
46	VPC Peering	VPC Peering을 사용하면 서로 다른 VPC 네트워크에 있는 인스턴스가 내부 IP 주소를 사용하여 통신할 수 있습니다. VPC Peering은 VPN보다 지연 시간이 짧고 처리량이 높습니다.
47	Cloud Storage Object Versioning	Cloud Storage Object Versioning을 활성화하면 객체의 모든 변경 사항이 보존되어 이전 버전을 참조하거나 복원할 수 있습니다. 이를 통해 실수로 인한 편집이나 삭제로부터 데이터를 보호할 수 있습니다.
48	Cloud VPN	두 조직의 Shared VPC 서브넷이 겹치는 경우, Cloud VPN을 사용하여 네트워크 연결을 설정할 수 있습니다. Cloud VPN은 서브넷이 겹치지 않는 애플리케이션 간 네트워크 연결을 제공하며, 최소한의 재구성으로 통합을 가능하게 합니다.
49	Cloud Logging과 Cloud Monitoring	애플리케이션 성능 저하 문제를 해결하려면 먼저 Cloud Logging과 Cloud Monitoring을 사용하여 인스턴스의 로그와 메트릭을 검사해야 합니다. 이를 통해 문제의 근본 원인을 파악하고 적절한 조치를 취할 수 있습니다.
50	조직 정책 (Organization Policy)	조직 정책을 사용하여 특정 도메인에만 IAM 사용자 권한을 부여하도록 제한하면, 외부 도메인에서 IAM 사용자가 권한을 얻는 것을 차단할 수 있습니다. 이를 통해 조직의 프로젝트를 안전하게 보호할 수 있습니다.
51	HorizontalPodAutoscaler (HPA)와 Node Auto Scaling	HPA는 워크로드의 트래픽이나 리소스 사용량에 따라 Pod의 수를 동적으로 조정하고, Node Auto Scaling은 클러스터의 노드 수를 자동으로 조정합니다. 이 둘을 함께 사용하면 GKE 클러스터의 비용을 절감하면서 가용성을 유지할 수 있습니다.
52	Liveness와 Readiness Probes	Liveness Probe는 컨테이너가 정상적으로 작동하는지 확인하고, Readiness Probe는 컨테이너가 트래픽을 받을 준비가 되었는지 확인합니다. 이 두 가지를 설정하면 GKE 롤링 업데이트 중 잘못된 설정으로 인해 발생하는 다운타임을 방지할 수 있습니다.
53	Cloud Logging Sink와 BigQuery	Cloud Logging Sink를 사용하여 BigQuery 데이터 액세스 로그를 BigQuery로 내보내면, BigQuery 쿼리를 통해 가장 비용이 많이 드는 쿼리와 사용자별 비용을 실시간으로 모니터링할 수 있습니다.
54	프로덕션 폴더와 Aggregated Export	프로덕션 프로젝트를 별도의 폴더에 구성하고, 해당 폴더에 대한 Aggregated Export를 설정하면, 프로덕션 프로젝트의 로그만 별도의 Cloud Storage 버킷에 저장하여 운영팀이 쉽게 액세스하고 관리할 수 있습니다.
55	Autoscaling Policy와 Memory Usage	메모리 사용량이 80%를 초과할 때 Compute Engine 애플리케이션을 자동 확장하려면, Autoscaling Policy에서 agent.googleapis.com/memory/percent_used 메트릭을 사용하고, 필터를 metric.label.state = 'used'로 설정해야 합니다.
56	Storage Transfer Service	대규모 데이터를 Cloud Storage로 마이
57	HA Cloud VPN	고가용성(HA) Cloud VPN은 99.99%의 SLA를 제공하는 VPN 연결 서비스입니다. 두 개의 터널을 사용하여 하나의 터널에 장애가 발생하더라도 다른 터널을 통해 연결을 유지할 수 있습니다.
58	Google Group과 폴더 기반 IAM	부서별 Google Group을 생성하고, 폴더별로 권한 상속을 제어하면 IAM 권한 관리를 효율적으로 수행할 수 있습니다.
59	Google Cloud Shell	Google Cloud Shell은 Google Cloud Console에서 직접 액세스할 수 있는 웹 기반 CLI 환경입니다. gcloud CLI가 사전 설치 및 구성되어 있어, 별도의 설치나 구성 없이 Google Cloud 리소스와 상호 작용할 수 있습니다.
60	Shutdown Script와 Pub/Sub	Shutdown Script는 Compute Engine 인스턴스가 종료될 때 실행되는 스크립트입니다. Shutdown Script에서 Pub/Sub 메시지를 발행하도록 구성하면 인스턴스 종료 이벤트를 안정적으로 처리할 수 있습니다.
61	Google Workspace와 조직 구조	별도의 Google Workspace 계정과 조직을 생성하거나, 폴더를 사용하여 개발자와 프로덕션 프로젝트를 분리하고, 조직 정책을 통해 중앙에서 정책을 관리할 수 있습니다. 이를 통해 개발자의 프로젝트 생성 자율성을 보장하면서 프로덕션 프로젝트에 대한 보안을 강화할 수 있습니다.
62	Cloud Storage Signed URL	Cloud Storage Signed URL을 사용하면 사용자가 App Engine을 통하지 않고 브라우저에서 Cloud Storage로 파일을 직접 업로드할 수 있습니다. POST URL을 생성하여 업로드 권한을 부여하고, CORS 구성을 통해 App Engine 애플리케이션의 base URL을 허용된 오리진으로 설정해야 합니다.
63	Cloud NAT	Cloud NAT를 사용하면 공용 IP 주소가 없는 인스턴스가 인터넷에 액세스할 수 있습니다. 이를 통해 sub-b의 인스턴스가 외부 저장소에 연결하여 업데이트된 패키지를 다운로드할 수 있습니다.
64	Sole-Tenancy와 BYOL	Sole-Tenancy 인스턴스를 사용하면 단일 호스트 서버에서 VM을 실행할 수 있습니다. 온프레미스 Windows Server 라이선스를 Google Cloud로 가져오려면 BYOL(Bring Your Own License) 방식을 사용해야 합니다. 온프레미스 VM의 이미지를 가져와 --os=windows-2022-dc-v 옵션으로 가상 디스크를 생성하고, Sole-Tenancy 인스턴스의 부팅 디스크로 사용해야 합니다.
65	HA Cloud VPN과 SLA	**99.99% 가용성(SLA)**을 충족하려면 HA Cloud VPN을 사용해야 합니다. 두 개의 HA Cloud VPN 게이트웨이와 두 개의 온프레미스 VPN 게이트웨이를 구성하고, 각 HA Cloud VPN 게이트웨이에 두 개의 터널을 생성하여 총 네 개의 터널을 구성해야 합니다.
66	Data Transfer Appliance	Data Transfer Appliance는 대규모 데이터를 오프라인으로 Google Cloud로 전송하는 데 사용됩니다. 10TB 온프레미스 데이터베이스를 Cloud Storage로 마이그레이션할 때, 네트워크 대역폭(1Gbps)을 고려하여 Data Transfer Appliance를 사용하는 것이 가장 빠르고 비용 효율적인 방법입니다.
67	Cloud Storage Bucket Lock	Cloud Storage Bucket Lock을 사용하면 **보존 정책(Retention Policy)**을 설정하여 객체가 삭제되거나 수정되지 않도록 보호할 수 있습니다. 이를 통해 규정 준수 요구 사항(5년 동안 보존)을 충족할 수 있습니다.
68	Cloud Load Balancing과 Backend Pool	Cloud Load Balancing을 사용하면 동일한 SSL 및 DNS 레코드를 유지하면서 여러 API 버전을 관리할 수 있습니다. 별도의 Backend Pool을 사용하여 각 API 버전에 대한 트래픽을 라우팅할 수 있습니다.
69	Autoscaling Policy와 Memory Usage Filter	Compute Engine Autoscaling Policy에서 메모리 사용량이 80%를 초과할 때 인스턴스를 확장하려면, agent.googleapis.com/memory/percent_used 메트릭을 사용하고, 필터를 metric.label.state = 'used'로 설정해야 합니다.