[GCP] ACE(Associate Cloud Engineer) 후기
[GCP] ACE(Associate Cloud Engineer) 후기와 요점 정리
아주 간단한 후기
GCP를 공부하면서 Google Cloud의 자격증 중 입문급 자격증인 Associate Cloud Engineer를 치르고 왔습니다.
이왕 보는 거 상위 시험인 PCA(Professional Cloud Architect)를 보라고 이야기해주신 분도 계셨어서 고민을 좀 했는데, 첫 GCP 시험으로 ACE를 선택한 것이 나쁘지 않은 선택을 한 것 같습니다.
개인적으로 GCP에 대한 지식 수준은, 이전에 구글 스터디잼을 몇번 참가해서 퀵랩 맛만 조금 봤고, 실무에서 GCP를 사용해본 경험은 없는 상태였습니다.
그래도 클라우드에 익숙한 경험이 도움이 될 것이라 생각했고, Professional이 아닌 입문급 자격증이니 좀 할만하지 않을까 생각했는데, 처음에 내용을 보니 생각처럼 쉽지는 않았습니다.
물론 AWS, GCP등 클라우드 프로바이더간 기본 컨셉은 공유하는 것이 많기는 하지만, specific config에 대해서 묻는 문제도 꽤 있구요. 그래서 원래 짧게 잡았던 일정에서 시험을 한번 미루기도 했습니다.
문제은행만 바짝 풀어서 어떻게든 급하게 치러볼 수도 있었겠지만 진짜 목적은 통과가 아니라 GCP의 기본 컨셉들을 찬찬히 최대한 학습하는 거니까요.
근데 서운하게 ACE는 왜 기념품으로 티셔츠 하나조차 주지 않는거죠? 그걸 진작 알았다면 PCA를…(이 부분에서 좀 후회가…)
아래에서 1. 시험 기본 정보, 2. (개인적인) 시험 준비 방식 3. 요점 정리 순으로 정리하겠습니다.
기본적인 정보는 다른 후기에서도 너무 많으니 간단하게만 훑으면,
- 비용: $75 (온라인 할인)
- 시험방식: 온라인
- 시간/문제수: 2시간, 객관식 50문제
시험 준비는, (1) Coursera, (2) 문제은행, (3) 구글 공식 문서를 활용했습니다.
처음에는 먼저 GCP와 친해지기 위해 Coursera에서
- Google Cloud Fundamentals: Core Infrastructure
- Preparing for the Google Cloud Associate Cloud Engineer Exam
두 강좌를 꼼꼼히 들었습니다.
추가로 Getting Started with Google Kubernetes Engine 는 빠르게 훑었는데, 만약 시간이 충분하다면 ACE 준비 커리큘럼(Preparing for Google Cloud Certification: Cloud Engineer Professional Certificate)을 모두 듣는 것을 추천하고 싶습니다. 현재는 시간 여유를 갖고 PCA를 준비하면서 틈틈이 다른 강좌를 모두 듣고 있습니다.
그러나 이 강좌들만으로 시험을 보기에는 절대적으로 부족합니다.
다음에는 문제은행을 제공하는 사이트들에서 연습문제를 풀면서 문제 유형을 익히고 주요 내용이나 부족한 내용을 구글 공식 문서로 훑어보았습니다.
아무래도 객관식 문제은행형 시험이다보니 문제를 푸는 것이 큰 도움이 되었습니다. 공식 문서가 가장 중요한 건 당연하구요!
아래에 후기가 괜찮은 사이트들을 몇개 리스팅 했습니다.
- 기본은 Google Cloud에서 제공하는 연습문제 조금.
기본적인 문제 유형 감을 잡아보기 위해 일찌감치 해보면 좋을 듯. - Examtopics
무료로도 문제를 풀어볼 수 있는데, 대신 자비 없이 capcha를 매번 네 문제마다 풀게합니다.. $16 아끼려고 수십번 capcha 하다보면 자괴감이…
그리고 ‘답’을 제공하는데 그건 왜 제공하는지 의아해집니다. 80% 정도는 답이 틀려있습니다. 그냥 기능을 빼지…?
사이트에서 제공하는 답 대신 답을 잘 정리해주신 네이버 블로그가 있어서 아주 유용하게 참고했습니다. (감사합니다.) - Acloud
강의 + 연습문제를 모두 제공.
일주일 무료 체험 기간을 주기 때문에 딱 그 사이에 다 마치고 계약을 해지하면 무료로 공부할 수 있…ㅎㅎ;
최소단위인 월 수강은 $35. - vmexam
1000문제 정도 되는 문제은행에서 끊임없이 연습시험을 볼 수 있습니다. 문제 pool이 가장 큰 것 같습니다.
문제은행 가격은 $26.90.
오답노트를 만들고, 오답노트에서 자주 나오는 유형에 대해서는 GCP 공식 문서를 보면서 추가로 내용을 정리했습니다.
아래는 테스트를 준비하면서 정리 해둔 내용입니다. 따라서 모든 영역을 커버하는 것이 아니라, 개인적인 요점 정리입니다.
Sections
- VPC (Subnet, Loadbalancer + Firewall)
- Logging
- IAM (Identity and Access Management)
- Billing
- CLIs
- GKE (Google Kubernetes Engine)
문제를 풀다 보니 개인적으로 IAM이나 CLI 등의 specific config나 command에 대해 묻는 문제들이 좀 까다로웠습니다. 다행히 해당 유형의 문제가 나올 때 (치사하게(?)) 구석구석 숨어있는 내용을 물어보는 것은 아니고, 주요 설정과 커맨드 위주로 물어보는 것으로 보입니다. 그래서 문제은행에서 나오는 유형과 공식 문서를 한번 훑어보고 나면 시험에서도 그 내용에서 벗어나지는 않았던 것 같습니다.
아래 모든 자료의 소스는 GCP 공식 문서입니다. 섹션별로 링크를 첨부했습니다.
1. VPC (Subnet, Loadbalancer + Firewall)
(1) VPC Overview
a. VPC : Global Resource!
VPC는 글로벌, 서브넷은 리전 단위이므로, 글로벌 서비스의 경우 한 VPC 안에 리전별 서브넷을 두고 내부망처럼 서비스 가능함.
VPC 네트워크는 연결된 라우터와 방화벽 규칙을 포함하여 Global Resource입니다. VPC 네트워크는 특정 리전 또는 영역과 연결되지 않습니다.
VPC 네트워크 내의 리소스는 관련 네트워크 방화벽 규칙에 따라 내부 IPv4 주소를 사용하여 서로 통신할 수 있습니다. 자세한 내용은 네트워크 내 통신을 참조하세요.
Subnet은 Region Resource입니다. 각 서브넷은 IP 주소 범위를 정의합니다.
b. 트래픽 제어
트래픽 제어, 로깅은 VM 단위.
인스턴스에서 송수신되는 트래픽은 네트워크 방화벽 규칙으로 제어할 수 있습니다. 규칙은 VM 자체에서 구현되므로 VM에서 나가거나 도착할 때만 트래픽을 제어하고 로깅할 수 있습니다.
c. VPC 통합
Shared VPC는 조직 내 여러 프로젝트들을 한 VPC 내부망 안에 합칠 수 있는 것이고, VPC Network Peering은 네트워크 관리 도메인이 구분된 복수의 VPC를 내부IP로 연결이 가능하도록 제공하는 기능임. 다른 팀이 쓰는 VPC랑 내부망 통신이 필요할 때 같은.
Organization에서는 Shared VPC를 사용하여 VPC 네트워크를 공용 호스트 프로젝트에 유지할 수 있습니다. 동일한 조직의 다른 프로젝트에서 승인된 IAM 구성원은 공유 VPC 네트워크의 서브넷을 사용하는 리소스를 만들 수 있습니다.
VPC Network Peering을 사용하여 VPC 네트워크를 다른 프로젝트 또는 Organization의 다른 VPC 네트워크에 연결할 수 있습니다.
d. Hybrid 환경
온프렘 환경과 VPC 연결 시
Cloud VPN이나 Cloud Interconnect를 사용하여 하이브리드 환경에서 VPC 네트워크를 안전하게 연결할 수 있습니다.
(2) Subnet
- 각 VPC 네트워크는 서브넷이라는 하나 이상의 IP 범위 파티션으로 구성됩니다.
- 각 서브넷은 리전과 연결됩니다.
- VPC 네트워크에는 IP 주소 범위가 연결되어 있지 않으며, IP 범위는 서브넷에 대해 정의됩니다.
- Range of Private IP addresses
10.0.0.0/8172.16.0.0/12192.168.0.0/16
(3) Shared VPC
- Shared VPC를 사용하는 Organization은 여러 프로젝트의 리소스를 한 VPC 네트워크에 연결할 수 있으므로 해당 네트워크의 내부 IP를 사용하여 안전하고 효율적으로 통신할 수 있습니다.
- 공유 VPC를 사용할 때는 프로젝트 하나를 호스트 프로젝트로 지정하고 여기에 하나 이상의 다른 서비스 프로젝트를 연결합니다.
- 서비스 프로젝트의 리소스는 Share VPC의 서브넷을 사용할 수 있습니다.
- Shared VPC를 사용하면 조직 관리자가 서브넷, 경로, 방화벽과 같은 네트워크 리소스를 중앙에서 제어하면서 서비스 프로젝트 관리자에게 인스턴스 생성 및 관리와 같은 관리 책임을 위임할 수 있습니다.
(4) VPC Peering
Google Cloud VPC 네트워크 피어링은 동일한 프로젝트에 속하는지 또는 동일한 조직에 속하는지에 관계없이 두 개의 Virtual Private Cloud(VPC) 네트워크에서 내부 IP 주소 연결을 허용합니다.
- 사용 환경:
- Google Cloud의 SaaS(Software-as-a-Service) 생태계. 조직 내 및 조직 간 서로 다른 VPC 네트워크에서 서비스를 비공개로 제공할 수 있습니다.
- 내부 IP 주소를 사용하여 통신해야 하는 네트워크 관리 도메인이 여러 개 있는 조직 - 이점(외부 네트워크 대비)
- 네트워크 지연 시간: 외부 주소를 사용하는 연결보다 지연 시간이 짧습니다.
- 네트워크 보안: 공개 인터넷에 서비스를 노출 X
- 네트워크 비용: Google Cloud는 트래픽이 같은 영역 내에 있더라도 외부 IP를 사용하여 통신하는 네트워크에 이그레스 대역폭 가격을 청구합니다. 그러나 피어링된 네트워크의 경우 내부 IP를 사용하여 통신하면 이러한 이그레스 비용을 절약할 수 있습니다.
(5) Hybrid Network with On-premises
Cloud VPN 또는 Cloud Interconnect를 사용하여 온프레미스 네트워크를 VPC 네트워크에 안전하게 연결.
a. Cloud VPN
Cloud VPN은 IPsec VPN 연결을 통해 피어 네트워크를 Virtual Private Cloud(VPC) 네트워크에 안전하게 연결합니다.
IPsec VPN 터널은 트래픽이 공개 인터넷을 거칠 때 업계 표준 IPsec 프로토콜을 사용하여 데이터를 암호화하여 보호합니다.
b. Cloud Interconnect
Cloud Interconnect는 지연 시간이 짧고 가용성이 높은 연결을 제공하므로 온프레미스 네트워크와 Google Cloud Virtual Private Cloud(VPC) 네트워크 간에 안정적으로 데이터를 전송할 수 있습니다. 또한 Interconnect 연결은 내부 IP 주소 통신을 제공하므로 양측 네트워크 모두에서 내부 IP 주소에 직접 액세스할 수 있습니다.
- Dedicated Interconnect는 온프레미스 네트워크와 Google 네트워크 간에 물리적인 직접 연결을 제공합니다.
- Partner Interconnect는 지원되는 서비스 제공업체를 통해 온프레미스 네트워크와 VPC 네트워크 간의 연결을 제공합니다.
장점 of Cloud Interconnect
- 온프레미스 네트워크와 VPC 네트워크 간의 트래픽이 공개 인터넷을 거치지 않습니다. 트래픽은 전용 연결이나 전용 연결을 갖춘 서비스 제공업체를 통해 전달됩니다. 공개 인터넷을 거치지 않아 트래픽 홉 수가 감소하므로 트래픽이 손실되거나 중단될 수 있는 장애 지점도 감소합니다.
- 온프레미스 네트워크에서 직접 VPC 네트워크의 내부 IP 주소에 액세스할 수 있습니다. 내부 IP 주소에 연결하기 위해 NAT 기기나 VPN 터널을 사용할 필요가 없습니다. 자세한 내용은 IP 주소 지정 및 동적 경로를 참조하세요.
(6) Load Balancer
트래픽 유형별 적합한 Load Balancer 타입을 참고.
2. Logging
Google Cloud 프로젝트는 Compute Engine 또는 BigQuery와 같은 로그 항목을 생성하는 서비스를 사용하기 시작하면 로그 항목을 수신합니다. 또한 Cloud Monitoring을 AWS에 연결하거나, VM 인스턴스에 Logging 에이전트를 설치할 때, Logging API에서 entries.write 메서드를 호출할 때도 로그 항목을 가져옵니다.
로그 항목의 최소 요소:
- 타임스탬프: 이벤트 발생 시점 또는 Cloud Logging 수신 시점
- 로그 항목을 생성한 모니터링 리소스
- 구조화되지 않은 텍스트 데이터 or JSON 형식의 구조화된 텍스트 데이터로 제공되는 payload(a.k.a message)
- 로그가 속한 로그의 이름.
Logging Agent의 종류에는 GCE 기본 분석을 위한 Ops Agent와 애플리케이션 로그 분석을 할 수 있는 Legacy Logging Agent가 있습니다.
a. Ops Agent
Compute Engine 인스턴스에서 원격 분석을 수집하기 위한 기본 에이전트.
이 에이전트는 로깅과 측정항목을 단일 에이전트로 결합하여 로그 및 측정항목을 수집하는 YAML 기반 구성을 제공하며 대용량 로깅을 지원합니다.
b. Legacy Logging Agent
일반적인 타사 애플리케이션 및 시스템 소프트웨어에서 Logging으로 로그를 스트리밍합니다. 추가 로그를 스트리밍하도록 에이전트를 구성할 수 있습니다.
c. Audit Log
3. IAM(Identity and Access Management)
IAM은 대한 문제도 꽤 나오는 느낌입니다. 안보면 틀리기 쉽지만, 한번 보면 복잡한 내용은 없으므로 한번은 훑어보는 것이 좋을 것 같습니다.
a. Member/Role/Policy
- Member.
Member는 Google 계정(유저), 서비스 계정(앱 및 가상 머신), Google 그룹 또는 리소스에 액세스할 수 있는 Google Workspace나 Cloud ID 도메인일 수 있습니다. 구성원 ID는 사용자, 서비스 계정 또는 Google 그룹과 연결된 이메일 주소이거나 Google Workspace 또는 Cloud ID 도메인과 연결된 도메인 이름입니다. - Role.
역할은 권한의 모음입니다. 권한은 리소스에 대해 허용되는 작업을 결정합니다. 구성원에게 역할을 부여하면 역할에 포함된 모든 권한을 부여하게 됩니다. - Policy.
IAM 정책은 하나 이상의 구성원을 개별 역할에 결합하는 역할 binding 모음입니다. 리소스에 대해 누구(구성원)에게 어떠한 액세스 권한(역할)이 있는지 정의하려면 정책을 만들고 리소스에 연결합니다.
b. Role — Default, Predefined, Custom
- Default Role (primitive)
이전부터 Google Cloud Console에 제공되는 역할로, 소유자, 편집자, 뷰어 역할이 있습니다.
주의: 모든 Google Cloud 서비스에서 기본 역할에는 수천 가지 권한이 포함됩니다. 프로덕션 환경에서는 대체 역할이 없는 경우가 아니라면 기본 역할을 부여하지 말아야 합니다. 대신 니즈를 충족하지만 가장 제한된 사전 정의된 역할이나 커스텀 역할을 부여합니다. - Predefined Role
기본 역할보다 더욱 세부적으로 액세스 권한을 제어할 수 있는 역할입니다. 예를 들어 사전 정의된 역할 Pub/Sub 게시자(roles/pubsub.publisher)는 메시지를 Pub/Sub 주제에 게시할 수 있는 액세스 권한만 부여합니다. - Custom Role
사전 정의된 역할로 필요한 사항을 조직에 충족할 수 없는 경우 조직의 필요에 맞게 생성하는 커스텀 역할입니다.
c. Best Practices
문제 중 까다로울 수 있는 부분은, 보기 여러 개가 모두 원하는 결과에 도달할 수는 있는데, 이 중에 Google에서 권장하는 Best Practice가 무엇이냐를 묻는 경우가 종종 있습니다. 그래서 아래와 같은 Best Practice 관련 내용들이 있으면 한번씩 살펴보는 것도 좋을 듯 합니다.
정책을 리소스 수준이 아닌 조직 수준 및 프로젝트 수준에서 설정합니다. 새로운 리소스가 추가될 경우 상위 리소스의 정책이 자동으로 상속되도록 하기 위해서입니다. 예를 들어 자동 확장을 통해 새로운 가상 머신이 프로젝트에 추가되면 자동으로 프로젝트의 정책을 상속합니다.
가능하면 개별 사용자가 아닌 Google 그룹에 역할을 부여합니다. 이렇게 하면 IAM 정책을 업데이트하는 것보다 Google 그룹의 구성원을 관리하기가 더욱 쉽습니다. IAM 정책에 사용되는 Google 그룹의 소유권을 제어하세요.
최소 권한의 보안 원칙을 사용하여 IAM 역할을 부여합니다. 이를 통해 리소스에 필요한 최소한의 액세스 권한만 부여할 수 있습니다.
사전 정의된 적절한 역할을 찾으려면 사전 정의된 역할 참조를 참조하세요. 사전 정의된 적절한 역할이 없는 경우 자체 커스텀 역할을 만들 수도 있습니다.
필요한 최소 범위의 역할만 부여합니다. 예를 들어 Pub/Sub 주제에 메시지를 게시하기 위한 액세스 권한만 필요한 사용자에게 해당 주제의 게시자 역할을 부여합니다.
하위 리소스 정책은 상위 리소스 정책을 상속받습니다. 예를 들어 프로젝트 정책이 사용자에게 Compute Engine 가상 머신(VM) 인스턴스를 관리할 수 있는 권한을 부여하면 사용자는 각 VM에 설정한 정책에 관계없이 해당 프로젝트에서 모든 Compute Engine VM을 관리할 수 있습니다.
여러 프로젝트에 걸쳐 있는 사용자 또는 그룹에 역할을 부여해야 하는 경우 프로젝트 수준이 아닌 폴더 수준에서 역할을 설정합니다.
정책이 규정을 준수하는지 감사합니다. 감사 로그에
setIamPolicy()호출이 모두 기록되므로 정책이 만들어지거나 수정된 시점을 추적할 수 있습니다.
4. Billing
위의 IAM과 대부분 연결되는 내용인데, IAM중에서도 Billing 관련 문제가 가끔씩 나오는 것 같습니다.
- Organization Node를 사용하여 Google Cloud 리소스를 관리하고 Google Cloud 조직의 구성원인 경우, 새 Cloud Billing 계정을 만들려면 결제 계정 생성자여야 합니다.
특히 조직 내에서 Google Cloud 사용자이고 이 작업을 수행하려면 다음 권한이 있어야 합니다:billing.accounts.create
{
"bindings": [
{
"role": "roles/billing.admin",
"members": [
"group:finance-admins-group@example.com"
]
},
{
"role": "roles/billing.viewer",
"members": [
"group:developers@example.com"
]
}
],
"etag": "BwUjMhCsNvY=",
"version": 1
}- billing.admin 역할은 IT 부서에 프로젝트를 결제 계정에 연결하고, 프로젝트 결제를 중지하고, 고객에게 재판매하는 계정의 신용카드 정보를 볼 수 있는 권한을 부여합니다.
프로젝트 콘텐츠를 볼 수 있는 권한을 부여하지 않습니다. - 결제 계정 사용자 역할은 서비스 계정에 결제(프로젝트를 조직의 모든 프로젝트의 조직의 결제 계정과 연결)를 사용 설정하여 서비스 계정에서 결제가 필요한 API를 사용 설정할 수 있는 권한을 부여합니다.
- billing.viewer 역할을 통해 개발자가 결제 계정의 비용을 볼 수 있습니다.
5. CLIs
a. Cloud SDK
gsutil, bq, kubectl을 포함한 명령줄 도구 모음이 Cloud SDK와 함께 패키지로 제공됩니다. gsutil 도구에서는 명령줄을 사용해 Cloud Storage 버킷과 객체를 관리할 수 있습니다. bq를 사용하면 명령줄을 통해 BigQuery에서 쿼리를 실행하고 데이터 세트, 테이블, 항목을 조작할 수 있습니다. kubectl에서는 명령줄을 사용해 Kubernetes 컨테이너 클러스터를 배포하고 관리할 수 있습니다.
b. gcloud
gcloud CLI는 인증, 로컬 구성, 개발자 워크플로, Google Cloud API와의 상호작용을 관리합니다. gcloud 명령줄 도구를 사용하면 Compute Engine VM 인스턴스 생성, Google Kubernetes Engine 클러스터 관리, 명령줄에서 또는 스크립트 및 기타 자동화에서 App Engine 애플리케이션 배포와 같은 일반적인 클라우드 작업을 쉽게 수행할 수 있습니다.
c. gsutil
gsutil은 명령줄에서 Cloud Storage에 액세스하는 데 사용할 수 있는 Python 애플리케이션입니다. gsutil로 다음과 같은 광범위한 버킷 및 객체 관리 작업을 수행할 수 있습니다.
- 버킷 생성 및 삭제
- 객체 업로드, 다운로드, 삭제
- 버킷 및 객체 나열
- 객체 이동, 복사 및 이름 바꾸기
- 객체 및 버킷 ACL 수정
gsutil은 HTTPS 및 전송 계층 보안(TLS)을 사용하여 업로드 및 다운로드를 포함한 모든 작업을 수행합니다.
d. bq
bq 도구를 사용하면 명령줄을 통해 BigQuery에서 쿼리를 실행하고 데이터 세트, 테이블, 항목을 조작할 수 있습니다.
e. kubectl
kubectl 도구는 Kubernetes 클러스터를 더 효과적으로 제어할 수 있는 명령어를 제공합니다. kubectl을 사용하면 애플리케이션 배포, 클러스터 리소스의 검사와 관리, 로그 보기를 포함하여 광범위한 작업을 수행할 수 있습니다.
6. GKE
GCP 내의 단일 컴포넌트 중에는 GKE에 대한 질문이 상대적으로 많았던 것 같습니다.
혹시 시험 보시는 분들은 좋은 결과 있으시길 바라겠습니다!
Disclaimer
위 글의 내용은 개인적으로 ACE를 공부하면서 정리한 내용으로, Google의 공식 문서 및 의견과 다를 수 있습니다.
