Ngân hàng đề — Google Cloud Associate Cloud Engineer

Đáp án

A — Địa chỉ NỘI BỘ theo REGION (regional internal address).

Vì sao đúng

Mỗi VM luôn được cấp một IP nội bộ thuộc dải của subnet, và subnet của GCP là tài nguyên theo Region.

⚠ Điểm mấu chốt — subnet của GCP có phạm vi REGION:

VPC của Google Cloud là TOÀN CẦU
        ↓
    Nhưng SUBNET thuộc MỘT REGION
        ↓
    VM khởi chạy vào một subnet
        ↓
    → nhận IP nội bộ từ dải CIDR của subnet đó
    → nên IP nội bộ là REGIONAL

⚠ IP nội bộ cấp TỰ ĐỘNG, IP ngoài thì KHÔNG:

IP nội bộ (internal)
        ↓
    LUÔN được cấp tự động — VM nào cũng có
        ↓
IP ngoài (external)
        ↓
    CHỈ có nếu bạn yêu cầu
    → mặc định VM KHÔNG có IP công cộng
        ↓
    Đề nói "GCP tự động gán"
      → đang nói tới IP NỘI BỘ

Xem thêm câu #12471 (lô 131): cùng một câu hỏi, cùng đáp án và cũng cùng chữ cái A. Khoá nhất quán.

Vì sao các phương án khác sai

• B (regional external address) — đây là phương án gần nhất vì đúng phạm vi Region, nhưng IP ngoài KHÔNG được cấp tự động.

• D (global internal address) — IP nội bộ của VM luôn là regional. Địa chỉ nội bộ toàn cầu dùng cho mục đích khác (Private Service Access).

• C (global external address) — dành cho Global HTTP(S) Load Balancer với IP anycast, không phải cho VM.

Ghi nhớ

⚠ Bốn loại địa chỉ IP của GCP — bảng phải thuộc: | | Internal | External | |---|---|---| | Regional | IP của VM — cấp TỰ ĐỘNG từ subnet | IP công cộng của VM, Regional LB | | Global | dải cho Private Service Access | IP anycast của Global HTTP(S) LB | | Tĩnh hay tạm | cả hai đều có ephemeral và static | | | Chi phí | nội bộ miễn phí | IP tĩnh KHÔNG dùng thì BỊ TÍNH TIỀN |

Từ khoá nhận diện:

"IP tự động gán cho VM" → regional internal "IP cố định cho VM" → static external "IP toàn cầu cho load balancer" → global external, anycast "VM không có IP công cộng mà cần ra internet" → Cloud NAT "VM gọi API Google không qua internet" → Private Google Access

⚠ Khác biệt lớn giữa GCP và AWS về mạng: | | Google Cloud | AWS | |---|---|---| | VPC | TOÀN CẦU | theo Region | | Subnet | theo REGION | theo Availability Zone | | Firewall | áp cho cả VPC, nhắm bằng tag hoặc service account | security group gắn vào ENI | | Mở rộng subnet | mở rộng được dải IP | không đổi CIDR được |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | VM có IP gì | gcloud compute instances describe <ten> | | Có IP tĩnh nào bỏ không | gcloud compute addresses list --filter="status=RESERVED" | | Subnet dải nào | gcloud compute networks subnets describe <subnet> --region=<region> |

Và một khác biệt rất đáng nhớ khi chuyển từ AWS sang GCP: subnet của Google Cloud trải cả một Region, không phải một zone. Một subnet duy nhất phục vụ được VM ở mọi zone trong Region đó — đơn giản hơn nhiều so với việc phải tạo subnet cho từng AZ như bên AWS.

Đáp án

C — Người dùng KHÔNG có quyền IAM cho các đối tượng trong bucket; trước khi bật uniform bucket-level access, họ truy cập được nhờ ACL.

Vì sao đúng

Uniform bucket-level access VÔ HIỆU HOÁ hoàn toàn ACL, nên mọi quyền chỉ còn đến từ IAM.

⚠ Điểm mấu chốt — hai hệ thống phân quyền song song của Cloud Storage:

TRƯỚC khi bật uniform access
        ↓
    HAI hệ thống cùng hoạt động:
        ↓
    IAM  → phân quyền ở cấp BUCKET (và project)
    ACL  → phân quyền ở cấp TỪNG ĐỐI TƯỢNG
        ↓
    Một người có thể truy cập được nhờ
    BẤT KỲ hệ thống nào trong hai

SAU khi bật uniform access
        ↓
    ACL bị VÔ HIỆU HOÁ HOÀN TOÀN
        ↓
    → chỉ IAM còn hiệu lực
    → ai chỉ có quyền qua ACL thì MẤT quyền
        ↓
    Đúng hiện tượng trong đề

⚠ Và ACL KHÔNG bị xoá, chỉ bị bỏ qua:

Bật uniform access
        ↓
    ACL vẫn còn trong siêu dữ liệu
    nhưng KHÔNG được đánh giá nữa
        ↓
    Trong 90 NGÀY đầu
        ↓
    → TẮT lại được, ACL hoạt động trở lại
        ↓
    Sau 90 ngày
        ↓
    → KHÔNG tắt lại được — quyết định vĩnh viễn

⚠ Cách khắc phục cho người dùng bị mất quyền:

Gán vai trò IAM tương ứng:
        ↓
    roles/storage.objectViewer   → đọc đối tượng
    roles/storage.objectCreator  → tạo đối tượng
    roles/storage.objectAdmin    → toàn quyền đối tượng
    roles/storage.admin          → cả bucket lẫn đối tượng
        ↓
    Cần phân quyền HẸP HƠN bucket?
        ↓
    → dùng IAM Conditions với tiền tố tên đối tượng
    → hoặc tách thành nhiều bucket

Vì sao các phương án khác sai

• B (người dùng thiếu quyền qua ACL; trước đó họ truy cập được nhờ IAM) — đây là phương án gần nhất và là bẫy chính: nó đảo ngược đúng chiều. Uniform access giữ IAM và bỏ ACL, chứ không phải ngược lại.

• D (ACL bị xoá khi bật, phải tạo lại) — ACL không bị xoá, chỉ bị bỏ qua. Và tạo lại ACL cũng vô nghĩa vì chúng không còn được đánh giá.

• A (mọi quyền bị xoá, không ai có quyền cho tới khi đặt lại) — sai: quyền IAM vẫn hoạt động bình thường, chỉ những ai phụ thuộc ACL mới mất quyền.

Ghi nhớ

⚠ IAM ↔ ACL trong Cloud Storage — bảng phải thuộc: | | IAM | ACL (cũ) | |---|---|---| | Cấp phân quyền | project, BUCKET | từng ĐỐI TƯỢNG | | Quản lý | tập trung, nhất quán với phần còn lại của GCP | rải rác trên từng đối tượng | | Uniform access | giữ lại | VÔ HIỆU HOÁ | | Khuyến nghị | dùng IAM | tránh — cơ chế cũ | | Kiểm toán | dễ | rất khó — phải quét từng đối tượng |

Từ khoá nhận diện:

"bật uniform bucket-level access rồi mất quyền" → họ đang dựa vào ACL "phân quyền hẹp hơn bucket" → IAM Conditions, hoặc tách bucket "ép mọi bucket dùng uniform access" → Organization Policy storage.uniformBucketLevelAccess "kiểm tra bucket có public không" → IAM Recommender / Security Command Center "90 ngày" → hạn chót để tắt lại uniform access

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bucket đã bật uniform chưa | gcloud storage buckets describe gs://<ten> → uniformBucketLevelAccess | | Ai có quyền gì | gcloud storage buckets get-iam-policy gs://<ten> | | Có ACL nào còn sót | gcloud storage objects describe gs://<ten>/<tep> --format="value(acl)" |

Và một việc bắt buộc phải làm trước khi bật uniform access trên bucket đang phục vụ: quét ACL hiện có và gán quyền IAM tương ứng trước. Nếu bật trước rồi mới sửa, bạn sẽ có một khoảng thời gian ứng dụng và người dùng đồng loạt nhận lỗi 403 — đúng loại sự cố mà một lượt kiểm tra vài phút có thể tránh hoàn toàn.

Đáp án

A — Triển khai VPC NETWORK PEERING giữa các VPC.

Vì sao đúng

Chi tiết quyết định: NHIỀU TỔ CHỨC. Shared VPC không vượt qua ranh giới tổ chức, peering thì có.

⚠ Điểm mấu chốt — peering nối được qua ranh giới tổ chức:

VPC Network Peering
        ↓
    Nối HAI mạng VPC riêng biệt
        ↓
    Hoạt động khi hai VPC ở:
      - cùng project
      - khác project
      - KHÁC TỔ CHỨC          ← trường hợp của đề
        ↓
    Lưu lượng đi trên MẠNG NỘI BỘ của Google
    → không qua internet, không tốn phí gateway

⚠ Vì sao Shared VPC không dùng được:

Shared VPC
        ↓
    Host project và service project
    PHẢI CÙNG MỘT TỔ CHỨC
        ↓
    Đề nói rõ "multiple organizations"
        ↓
    → loại ngay

⚠ Ba ràng buộc của peering phải nhớ:

1. KHÔNG BẮC CẦU
    A↔B và B↔C → KHÔNG cho A↔C

2. CIDR KHÔNG ĐƯỢC CHỒNG LẤN
    → phải quy hoạch IP từ đầu

3. PHẢI TẠO Ở CẢ HAI PHÍA
    → chỉ một bên tạo → trạng thái INACTIVE

Xem thêm câu #12470 (lô 131): cùng một câu hỏi, cùng đáp án VPC Peering. Chỉ khác chữ cái — ở đó là B, ở đây là A. Và #12467/#12497 (lô 131): nhiều PROJECT cùng tổ chức thì khoá là Shared VPC — khoá khác nhau vì phạm vi khác nhau, không mâu thuẫn.

Vì sao các phương án khác sai

• B (Shared VPC) — đây là phương án gần nhất và là đáp án đúng cho một đề rất giống, nhưng nó chỉ hoạt động TRONG MỘT tổ chức.

• D (VPN giữa các VPC) — chạy được nhưng thua peering ở mọi mặt khi cả hai đầu đều trong Google Cloud: có phí gateway, giới hạn băng thông mỗi đường hầm, thêm độ trễ mã hoá.

• C (firewall rule cho phép lưu lượng ra tới VPC khác) — firewall không tạo ra đường đi.

Ghi nhớ

⚠ Bốn cách nối mạng của GCP — bảng phải thuộc: | Cách | Phạm vi | |---|---| | Shared VPC | CHỈ trong một tổ chức — một VPC dùng chung | | VPC Peering | cùng hoặc KHÁC tổ chức — hai VPC riêng, nối lại | | Cloud VPN | tới mạng ngoài, có mã hoá, có phí gateway | | Cloud Interconnect | tới trung tâm dữ liệu, băng thông lớn | | Network Connectivity Center | trung tâm nối, giải bài toán không bắc cầu |

Từ khoá nhận diện:

"nhiều TỔ CHỨC" → VPC Peering "nhiều project CÙNG tổ chức, một mạng chung" → Shared VPC "nối với trung tâm dữ liệu" → Cloud VPN hoặc Interconnect "nhiều VPC nối chằng chịt" → Network Connectivity Center "gọi dịch vụ bên khác qua IP riêng" → Private Service Connect

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Peering hoạt động chưa | gcloud compute networks peerings list → phải ACTIVE | | Route đã trao đổi chưa | gcloud compute routes list --filter="peering" | | Máy gọi được nhau không | ping hoặc nc giữa hai VM bằng IP riêng |

Và một điều nên xác nhận sớm trước khi hứa tiến độ: hai VPC có dải IP chồng lấn hay không. Peering từ chối thẳng nếu CIDR trùng, và cách sửa duy nhất là đánh số lại toàn bộ một bên — công việc rất tốn kém mà vài phút quy hoạch ở giai đoạn thiết kế đã tránh được.

Đáp án

B và C — STDOUT và STDERR.

Vì sao đúng

Đây là quy ước chuẩn của cả hệ sinh thái container: ứng dụng ghi log ra luồng đầu ra chuẩn, và nền tảng lo phần thu thập.

⚠ Điểm mấu chốt — đường đi của một dòng log trong GKE:

Container ghi ra STDOUT hoặc STDERR
        ↓
    Runtime của container ghi lại vào
    tệp log trên node
      /var/log/containers/...
        ↓
    Agent thu log của GKE (chạy dạng DaemonSet)
    đọc các tệp đó
        ↓
    Đẩy lên CLOUD LOGGING
        ↓
    → tự động, không phải cấu hình gì
    → và log CÒN LẠI sau khi pod biến mất

⚠ Vì sao đây là cách đúng cho container:

Ghi log vào TỆP bên trong container
        ↓
    → mất khi container bị xoá
    → phải gắn volume, phải xoay tệp
    → phải cài agent riêng

Ghi ra STDOUT/STDERR
        ↓
    → không giữ trạng thái nào
    → nền tảng lo mọi thứ còn lại
        ↓
    Đây là nguyên tắc của "Twelve-Factor App":
      "coi log là một LUỒNG SỰ KIỆN"

⚠ Và một cải tiến rất đáng làm — log có cấu trúc:

Ghi log dạng JSON ra stdout
        ↓
    {"severity":"ERROR","message":"...",
     "userId":"123","traceId":"..."}
        ↓
    Cloud Logging TỰ PHÂN TÍCH các trường
        ↓
    → lọc theo severity, truy vấn theo trường
    → nối được với Cloud Trace qua traceId
        ↓
    Trường "severity" đặc biệt:
      Cloud Logging dùng nó để phân loại
      mức độ nghiêm trọng

Vì sao các phương án khác sai

• D (SYSLOG) — đây là phương án gần nhất vì syslog là một cơ chế log có thật của Linux, nhưng nó không phải cách GKE thu log của ứng dụng trong container. (Log hệ thống của node thì có được thu, nhưng đó là chuyện khác.)

• A (SYSERR) — không tồn tại. Tên đúng của luồng lỗi chuẩn là stderr.

Ghi nhớ

⚠ Log trong GKE — bảng phải thuộc: | Nguồn | Thu thế nào | |---|---| | Ứng dụng ghi ra stdout / stderr | TỰ ĐỘNG lên Cloud Logging | | Log hệ thống của node | agent thu, vào Cloud Logging | | Sự kiện của Kubernetes | vào Cloud Logging | | Audit log của cụm | vào Cloud Audit Logs | | Ghi vào tệp trong container | KHÔNG được thu — mất khi pod chết |

Từ khoá nhận diện:

"GKE thu log ứng dụng ở đâu" → stdout và stderr "log mất khi pod bị xoá" → đang ghi vào tệp, không ra stdout "lọc log theo trường" → ghi log dạng JSON có cấu trúc "nối log với vết truy tìm" → trường trace hoặc traceId "giảm chi phí log" → exclusion filter trong Cloud Logging

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Log có lên Cloud Logging không | Logs Explorer, lọc resource.type="k8s_container" | | Ứng dụng ghi ra đâu | kubectl logs <pod> — nếu trống thì không ghi ra stdout | | Chi phí log bao nhiêu | Billing, mục Cloud Logging |

Và một thay đổi nhỏ ở phía ứng dụng mang lại lợi ích rất lớn: ghi log dạng JSON ra stdout thay vì văn bản thuần. Cloud Logging tự nhận ra từng trường, bạn lọc được theo severity và truy vấn theo bất kỳ trường nào — thay vì phải viết biểu thức chính quy mỗi lần định dạng thông báo thay đổi một chút.

Đáp án

D — gcloud compute snapshots describe

Vì sao đúng

Cần thông tin chi tiết của MỘT snapshot cụ thể, và động từ cho việc đó luôn là describe.

⚠ Điểm mấu chốt — list ↔ describe:

gcloud compute snapshots list
        ↓
    LIỆT KÊ nhiều snapshot
    → chỉ vài trường tóm tắt
        ↓
gcloud compute snapshots describe <ten>
        ↓
    CHI TIẾT của MỘT snapshot
    → bao gồm sourceDisk, sourceDiskId,
      diskSizeGb, storageBytes, creationTimestamp,
      storageLocations, labels
        ↓
    → trường `sourceDisk` chính là thứ đề cần

⚠ Và cấu trúc lệnh: nhóm trước, động từ sau:

gcloud  compute  snapshots  describe
          ↑          ↑          ↑
        nhóm     nhóm con    động từ
        ↓
    → "gcloud snapshots describe" thiếu nhóm compute
    → "gcloud compute disk describe" sai nhóm con
      (và phải là `disks`, số nhiều)

⚠ Mẹo lấy nhanh nguồn của MỌI snapshot:

gcloud compute snapshots list \
  --format="table(name, sourceDisk, diskSizeGb, creationTimestamp)"
        ↓
    → `--format` lấy được cả những trường
      mà bảng mặc định không hiện
        ↓
    → không cần describe từng cái một

Vì sao các phương án khác sai

• A (gcloud compute snapshots list) — đây là phương án gần nhất và là lệnh có thật, nhưng nó liệt kê chứ không cho chi tiết. (Trừ khi thêm --format để ép hiện thêm trường — nhưng đề hỏi lệnh lấy thông tin chi tiết.)

• B (gcloud snapshots describe) — thiếu nhóm compute. Không có nhóm cấp cao nào tên snapshots.

• C (gcloud compute disk describe) — sai hai chỗ: nhóm con phải là disks (số nhiều), và nó mô tả đĩa, không phải snapshot.

Ghi nhớ

⚠ Các lệnh snapshot của Compute Engine — bảng đáng thuộc: | Lệnh | Việc | |---|---| | gcloud compute snapshots list | liệt kê | | gcloud compute snapshots describe <ten> | chi tiết, có sourceDisk | | gcloud compute disks snapshot <dia> | tạo snapshot từ một đĩa | | gcloud compute snapshots delete <ten> | xoá | | gcloud compute disks create --source-snapshot=<ten> | tạo đĩa mới từ snapshot | | gcloud compute resource-policies create snapshot-schedule | lịch snapshot tự động |

Từ khoá nhận diện:

"thông tin chi tiết một tài nguyên" → describe "liệt kê nhiều tài nguyên" → list "snapshot tự động theo lịch" → snapshot schedule (resource policy) "khôi phục từ snapshot" → tạo ĐĨA MỚI từ snapshot "gcloud snapshots ..." → SAI — thiếu nhóm compute

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Snapshot này của đĩa nào | gcloud compute snapshots describe <ten> --format="value(sourceDisk)" | | Có snapshot nào mồ côi không | liệt kê rồi đối chiếu với danh sách đĩa hiện có | | Đĩa có lịch snapshot chưa | gcloud compute disks describe <dia> → resourcePolicies |

Và một nguồn lãng phí âm thầm rất phổ biến: snapshot của những đĩa đã bị xoá từ lâu. Chúng không hiện ra ở đâu dễ thấy nhưng vẫn được tính tiền hàng tháng — nên một lượt đối chiếu định kỳ giữa snapshots list và disks list, hoặc đơn giản là đặt thời gian giữ trong snapshot schedule, sẽ giải quyết vấn đề này một lần cho mãi mãi.

Đáp án

C — Cloud SQL.

Vì sao đúng

Hai ràng buộc: CSDL được quản lý cho ứng dụng quản lý kho hàng, và thị trường giới hạn ở một khu vực.

⚠ Điểm mấu chốt — quy mô KHU VỰC thì không cần CSDL toàn cầu:

Ứng dụng quản lý kho hàng
        ↓
    Là ứng dụng GIAO DỊCH (OLTP) điển hình:
      đọc ghi nhiều bản ghi nhỏ,
      cần khoá ngoại, giao dịch, chỉ mục
        ↓
    → CSDL QUAN HỆ
        ↓
    Thị trường một khu vực
        ↓
    → KHÔNG cần phân tán toàn cầu
    → Cloud SQL đủ, và RẺ HƠN NHIỀU

⚠ Cloud SQL cho gì:

MySQL, PostgreSQL, SQL Server được quản lý
        ↓
    Google lo: vá lỗi, sao lưu, nhân bản, failover
        ↓
    Tính năng sẵn sàng cao:
      - HA với standby ở zone khác
      - Read replica (kể cả cross-Region)
      - Point-in-time recovery
      - Sao lưu tự động

Xem thêm câu #12488 (lô 131): cùng một câu hỏi, cùng đáp án Cloud SQL. Chỉ khác chữ cái — ở đó là B, ở đây là C. Khoá nhất quán.

Vì sao các phương án khác sai

• D (Cloud Spanner) — đây là phương án gần nhất và hoàn toàn làm được, nhưng nó là giải pháp quá mức: chi phí tối thiểu cao hơn Cloud SQL rất nhiều, đổi lại khả năng phân tán toàn cầu mà bài toán không cần.

• A (Bigtable) — NoSQL, không có giao dịch nhiều dòng, không có SQL đầy đủ.

• B (Cloud Dataproc) — nền tảng Hadoop/Spark, không phải CSDL.

Ghi nhớ

⚠ Cloud SQL ↔ Cloud Spanner — bảng phải thuộc: | | Cloud SQL | Cloud Spanner | |---|---|---| | Động cơ | MySQL, PostgreSQL, SQL Server | riêng của Google | | Mở rộng | DỌC + read replica | NGANG, không giới hạn | | Phạm vi | theo Region | nhiều Region, toàn cầu | | Chi phí tối thiểu | thấp | cao hơn nhiều | | Dùng khi | hầu hết ứng dụng thông thường | quy mô rất lớn, nhiều Region |

Từ khoá nhận diện:

"CSDL quan hệ, quy mô khu vực" → Cloud SQL "giao dịch toàn cầu, nhất quán mạnh" → Cloud Spanner "phân tích, kho dữ liệu" → BigQuery "NoSQL ghi rất nhiều" → Bigtable "cần MySQL y như đang dùng" → Cloud SQL

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Instance có HA không | gcloud sql instances describe <ten> → availabilityType | | Có IP công cộng không | cùng lệnh, xem ipConfiguration | | Sao lưu có chạy không | gcloud sql backups list --instance=<ten> |

Và một nguyên tắc đáng theo khi chọn CSDL: bắt đầu từ lựa chọn đơn giản nhất đủ dùng. Cloud SQL phục vụ tốt phần lớn ứng dụng doanh nghiệp, và chuyển sang Spanner sau này khi thật sự chạm trần vẫn khả thi — trong khi chọn Spanner ngay từ đầu cho một thị trường một khu vực là khoản chi phí cố định rất khó biện minh.

Đáp án

D — Kiểm tra firewall rule có cho phép lưu lượng tới CỔNG 22 để SSH kết nối được không.

Vì sao đúng

gcloud compute scp chạy trên nền SSH, nên mọi thứ chặn SSH cũng chặn nó.

⚠ Điểm mấu chốt — firewall của GCP mặc định CHẶN mọi ingress:

gcloud compute scp
        ↓
    Bên dưới là SSH (cổng 22)
        ↓
    Firewall mặc định CHẶN mọi ingress
        ↓
    Không có luật cho phép cổng 22
        ↓
    → kết nối không thiết lập được
    → lệnh copy thất bại

⚠ Luật cần có:

Direction: INGRESS
Source:    35.235.240.0/20   (nếu dùng IAP)
           hoặc IP của người dùng
Protocol:  tcp:22
Target:    network tag của VM, hoặc service account
        ↓
    Mạng "default" có sẵn luật default-allow-ssh
    → VPC tự tạo thì KHÔNG có, phải tự thêm

⚠ Cách hiện đại hơn — IAP TCP forwarding:

gcloud compute scp <tep> <vm>: --tunnel-through-iap
        ↓
    → VM KHÔNG cần IP công cộng
    → chỉ mở cổng 22 cho dải 35.235.240.0/20
    → phân quyền bằng IAM
      (roles/iap.tunnelResourceAccessor)

Xem thêm câu #12475 (lô 131): cùng một câu hỏi, cùng đáp án. Chỉ khác chữ cái — ở đó là B, ở đây là D. Khoá nhất quán.

Vì sao các phương án khác sai

• A và B (cấp quyền compute.admin) — đây là các phương án gần nhất vì quyền cũng có thể là nguyên nhân, nhưng compute.admin quá rộng cho việc chỉ cần SSH, và quyền IAM không mở được đường mạng. (Quyền tối thiểu để SSH là roles/compute.osLogin.)

• C (thêm danh tính vào "administrator group" của VM) — không có khái niệm nhóm quản trị của VM trong Google Cloud. Quyền cấp bằng IAM, đăng nhập hệ điều hành quản bằng OS Login.

Ghi nhớ

⚠ Firewall của Google Cloud — bảng phải thuộc: | Đặc điểm | Nội dung | |---|---| | Mặc định | CHẶN mọi ingress, CHO PHÉP mọi egress | | Phạm vi | áp cho cả VPC | | Nhắm mục tiêu | network tag, service account, hoặc mọi instance | | Ưu tiên | 0-65535, số NHỎ HƠN thắng | | Cùng ưu tiên | DENY thắng ALLOW | | Có trạng thái | CÓ |

Từ khoá nhận diện:

"scp hoặc ssh thất bại" → firewall cổng 22, trước tiên "không muốn VM có IP công cộng" → IAP TCP forwarding "quản người dùng SSH tập trung" → OS Login "VM ra internet không có IP công cộng" → Cloud NAT "VM gọi API Google không qua internet" → Private Google Access

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có luật SSH không | gcloud compute firewall-rules list --filter="allowed.ports=22" | | VM có tag gì | gcloud compute instances describe <ten> --format="value(tags.items)" | | Vì sao không kết nối được | gcloud compute ssh <vm> --troubleshoot |

Và một lệnh rất đáng nhớ cho loại sự cố này: gcloud compute ssh <vm> --troubleshoot. Nó tự kiểm tra firewall, quyền IAM, trạng thái VM, OS Login và dải IAP rồi báo cáo chính xác mắt xích nào đang thiếu — nhanh hơn nhiều so với kiểm tra từng thứ bằng tay.

Đáp án

C — gcloud container images list

Vì sao đúng

Câu này kiểm tra cấu trúc lệnh gcloud: nhóm trước, nhóm con, rồi động từ.

⚠ Điểm mấu chốt — thứ tự của lệnh:

gcloud  container  images  list
          ↑          ↑       ↑
        nhóm     nhóm con  động từ
        ↓
    → "gcloud images container list" đảo nhóm
    → "gcloud container list metadata" đảo động từ
    → "gcloud container metadata list" sai nhóm con

⚠ Các lệnh liên quan trong nhóm này:

gcloud container images list
    → liệt kê image trong registry

gcloud container images list-tags <image>
    → liệt kê TAG và DIGEST của một image

gcloud container images describe <image>
    → chi tiết một image

gcloud container images delete <image>
    → xoá

⚠ Ghi nhớ về chất lượng câu hỏi

Đề nhắc tới Google Container Registry (GCR). Dịch vụ này đã ngừng phát triển và đang được thay thế bằng Artifact Registry — Google đã thông báo lộ trình ngừng hoạt động của GCR, và mọi dự án mới đều nên dùng Artifact Registry với nhóm lệnh gcloud artifacts.

Khoá đáp án không đổi: gcloud container images list vẫn là lệnh đúng cho GCR, và trong bốn phương án thì chỉ nó có cấu trúc hợp lệ. Nhưng khi làm việc thật hôm nay, hãy dùng gcloud artifacts repositories list và gcloud artifacts docker images list — xem thêm câu #12474 (lô 131) về Artifact Registry.

Vì sao các phương án khác sai

• B (gcloud container metadata list) — đây là phương án gần nhất vì nhóm container đúng, nhưng không có nhóm con metadata.

• A (gcloud images container list) — đảo ngược nhóm và nhóm con.

• D (gcloud container list metadata) — động từ đặt sai vị trí: gcloud luôn là nhóm trước, động từ sau.

Ghi nhớ

⚠ Container Registry ↔ Artifact Registry — bảng phải thuộc: | | Container Registry (GCR) | Artifact Registry | |---|---|---| | Trạng thái | CŨ, đang ngừng | HIỆN HÀNH | | Nhóm lệnh | gcloud container images | gcloud artifacts | | Định dạng | chỉ Docker | Docker, Maven, npm, Python, Go, Apt, Yum, Helm | | Tên miền | gcr.io | <location>-docker.pkg.dev | | Phân quyền | dựa vào quyền của bucket GCS | IAM ở mức REPOSITORY | | Khuyến nghị | — | mọi dự án mới |

Từ khoá nhận diện:

"Artifact Registry" → gcloud artifacts "Container Registry / GCR" → gcloud container images — dịch vụ cũ "GKE, cụm Kubernetes" → gcloud container clusters "quét lỗ hổng image" → Artifact Analysis "chặn image chưa duyệt chạy trên GKE" → Binary Authorization

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có những image nào | gcloud container images list (GCR) hoặc gcloud artifacts docker images list | | Tag và digest của một image | gcloud container images list-tags <image> | | Docker đã cấu hình chưa | gcloud auth configure-docker |

Và một tính năng rất nên bật khi chuyển sang Artifact Registry cho môi trường production: immutable tag. Nó ngăn việc đẩy đè lên một tag đã tồn tại, nên v1.2.3 hôm nay và v1.2.3 sáu tháng sau chắc chắn là cùng một image — điều kiện để việc điều tra sự cố và kiểm toán trở nên đáng tin cậy.

Đáp án

C — LABELS (nhãn).

Vì sao đúng

Label là cơ chế của Google Cloud để gắn siêu dữ liệu vào tài nguyên và chia nhỏ chi phí theo các chiều do bạn định nghĩa.

⚠ Điểm mấu chốt — label xuất hiện trong dữ liệu thanh toán:

Gắn label lên tài nguyên:
    team = data-platform
    env  = production
        ↓
    Label được đưa vào BILLING EXPORT
        ↓
    → xuất dữ liệu thanh toán sang BigQuery
    → truy vấn: chi phí GROUP BY label
        ↓
    → biết đội nào tốn bao nhiêu

⚠ Label ↔ Tag ↔ Network tag — ba thứ KHÁC NHAU:

LABEL
    → TỔ CHỨC và PHÂN TÍCH CHI PHÍ
    → xuất hiện trong billing export

TAG (Resource Manager tag)
    → ĐIỀU KIỆN IAM và ORGANIZATION POLICY

NETWORK TAG
    → chỉ để FIREWALL RULE nhắm mục tiêu

Xem thêm câu #12476 (lô 131): cùng một câu hỏi, cùng đáp án Labels. Chỉ khác chữ cái — ở đó là B, ở đây là C. Khoá nhất quán.

Vì sao các phương án khác sai

• B (Audit logs) — đây là phương án gần nhất vì audit log cho biết AI đã tạo tài nguyên, nhưng nó không có thông tin chi phí. Muốn ra con số tiền vẫn phải tự đối chiếu thủ công.

• A (Trace logs) — Cloud Trace theo dõi độ trễ của request, không liên quan tới chi phí.

• D (IAM policies) — quyết định AI ĐƯỢC LÀM GÌ, không phân loại tài nguyên theo đội.

Ghi nhớ

⚠ Ba loại "nhãn" trong Google Cloud — bảng phải thuộc: | Loại | Dùng để | |---|---| | Label | tổ chức và PHÂN TÍCH CHI PHÍ — vào billing export | | Tag (Resource Manager) | điều kiện IAM và Organization Policy | | Network tag | firewall rule nhắm mục tiêu | | Bẫy | ba thứ hoàn toàn khác nhau |

Từ khoá nhận diện:

"chi phí theo đội / dự án" → label + billing export "ai đã tạo tài nguyên" → Cloud Audit Logs "điều kiện IAM theo thuộc tính" → tag "firewall nhắm vào nhóm máy" → network tag hoặc service account "cảnh báo vượt ngân sách" → Budget và alert

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tài nguyên có label gì | gcloud compute instances describe <ten> --format="value(labels)" | | Chi phí theo đội | truy vấn billing export trong BigQuery, GROUP BY label | | Tài nguyên nào thiếu label | lọc --filter="-labels.team:*" |

Và một điểm cần lưu ý khi bắt đầu dùng label để chia chi phí: label chỉ áp cho chi phí phát sinh SAU khi gắn. Dữ liệu thanh toán tháng trước không tự có label mới, nên càng gắn sớm càng tốt — và với những khoản không gắn label được, cách tách bạch tuyệt đối vẫn là mỗi đội một project riêng.

Đáp án

B — gcloud datastore export gs://my-datastore-backup --async

Vì sao đúng

Đề đòi hai thứ: sao lưu ra Cloud Storage, và lệnh trả về ngay trong khi việc chạy nền.

⚠ Điểm mấu chốt — động từ là EXPORT, không phải backup:

Datastore / Firestore
        ↓
    Không có lệnh "backup"
        ↓
    Cơ chế sao lưu là XUẤT DỮ LIỆU (export)
    ra một bucket Cloud Storage
        ↓
    gcloud datastore export gs://bucket
        ↓
    Khôi phục:
      gcloud datastore import gs://bucket/...

⚠ Và --async là phần thứ hai của yêu cầu:

Không có --async
        ↓
    Lệnh CHỜ tới khi export xong
    → dữ liệu lớn có thể mất hàng giờ
        ↓
Có --async
        ↓
    Trả về NGAY, kèm một OPERATION ID
        ↓
    Theo dõi bằng:
      gcloud datastore operations list
      gcloud datastore operations describe <id>

Xem thêm câu #12473 (lô 131): cùng một câu hỏi, cùng đáp án và cũng cùng chữ cái B. Khoá nhất quán.

Vì sao các phương án khác sai

• D (gcloud datastore export gs://my-datastore-backup) — đây là phương án gần nhất và lệnh hoàn toàn đúng, nhưng thiếu --async: nó sẽ chờ tới khi export xong.

• A (gcloud datastore backup ...) — không có động từ backup.

• C (gsutil datastore export ...) — sai công cụ: gsutil chỉ làm việc với Cloud Storage.

Ghi nhớ

⚠ Sao lưu và khôi phục Datastore/Firestore — bảng phải thuộc: | Việc | Lệnh | |---|---| | Sao lưu | gcloud datastore export gs://bucket | | Khôi phục | gcloud datastore import gs://bucket/<duong-dan> | | Chạy nền | --async | | Theo dõi | gcloud datastore operations list / describe | | Xuất một phần | --kinds và --namespaces | | Bucket | nên CÙNG Region với database |

Từ khoá nhận diện:

"sao lưu Datastore/Firestore" → export ra Cloud Storage "lệnh trả về ngay" → --async "theo dõi việc chạy nền" → operations list / describe "gsutil quản lý dịch vụ khác" → luôn SAI "khôi phục về thời điểm" → Firestore PITR (7 ngày)

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Export xong chưa | gcloud datastore operations list | | Bản xuất nằm ở đâu | gcloud storage ls gs://my-datastore-backup | | Import có chạy được không | thử import vào project THỬ NGHIỆM |

Và một việc nên làm định kỳ với mọi cơ chế sao lưu: thử khôi phục thật vào một project thử nghiệm. Một bản xuất tồn tại trong bucket không chứng minh được gì cho tới khi bạn nạp lại thành công — và thời điểm phát hiện bản xuất bị hỏng chắc chắn không nên là lúc dữ liệu thật đã mất.