nerdexam
Google

PROFESSIONAL-CLOUD-ARCHITECT · Question #316

Case Study: 1 - Mountkirk Games Case Study Company Overview Mountkirk Games makes online, session-based. multiplayer games for the most popular mobile platforms. Company Background Mountkirk Games…

The correct answer is C. Workload identity. Workload Identity is the Google-recommended method for GKE pods to securely authenticate to GCP services by linking Kubernetes service accounts to Google Cloud service accounts - no key files to manage, no secrets to rotate, and it follows least-privilege principles natively…

Submitted by miguelv· Mar 30, 2026Designing for security and compliance

Question

Case Study: 1 - Mountkirk Games Case Study Company Overview Mountkirk Games makes online, session-based. multiplayer games for the most popular mobile platforms. Company Background Mountkirk Games builds all of their games with some server-side integration and has historically used cloud providers to lease physical servers. A few of their games were more popular than expected, and they had problems scaling their application servers, MySQL databases, and analytics tools. Mountkirk's current model is to write game statistics to files and send them through an ETL tool that loads them into a centralized MySQL database for reporting. Solution Concept Mountkirk Games is building a new game, which they expect to be very popular. They plan to deploy the game's backend on Google Compute Engine so they can capture streaming metrics, run intensive analytics and take advantage of its autoscaling server environment and integrate with a managed NoSQL database. Technical Requirements Requirements for Game Backend Platform 1. Dynamically scale up or down based on game activity. 2. Connect to a managed NoSQL database service. 3. Run customized Linx distro. Requirements for Game Analytics Platform 1. Dynamically scale up or down based on game activity. 2. Process incoming data on the fly directly from the game servers. 3. Process data that arrives late because of slow mobile networks. 4. Allow SQL queries to access at least 10 TB of historical data. 5. Process files that are regularly uploaded by users' mobile devices. 6. Use only fully managed services CEO Statement Our last successful game did not scale well with our previous cloud provider, resuming in lower user adoption and affecting the game's reputation. Our investors want more key performance indicators (KPIs) to evaluate the speed and stability of the game, as well as other metrics that provide deeper insight into usage patterns so we can adapt the gams to target users. CTO Statement Our current technology stack cannot provide the scale we need, so we want to replace MySQL and move to an environment that provides autoscaling, low latency load balancing, and frees us up from managing physical servers. CFO Statement We are not capturing enough user demographic data usage metrics, and other KPIs. As a result, we do not engage the right users. We are not confident that our marketing is targeting the right users, and we are not selling enough premium Blast-Ups inside the games, which dramatically impacts our revenue. For this question, refer to the Mountkirk Games case study. MountKirk Games uses Kubernetes and Google Kubernetes Engine. For the management, it is important to use an open platform, cloud-native, and without vendor lock-ins. But they also need to use advanced APIs of GCP services and want to do it securely using standard methodologies, following Google- recommended practices but above all efficiently with maximum security. Which of the following solutions would you recommend?

Options

  • AAPI keys
  • BService Accounts
  • CWorkload identity
  • DWorkload identity federation

How the community answered

(52 responses)
  • A
    8% (4)
  • B
    4% (2)
  • C
    71% (37)
  • D
    17% (9)

Explanation

Workload Identity is the Google-recommended method for GKE pods to securely authenticate to GCP services by linking Kubernetes service accounts to Google Cloud service accounts - no key files to manage, no secrets to rotate, and it follows least-privilege principles natively within the GCP ecosystem.

API keys (A) are coarse-grained identifiers with no identity binding; they can't be scoped to a specific workload and are considered insecure for service-to-service authentication - a poor fit for production GKE environments.

Service Accounts (B) are valid GCP identities, but using them in GKE without Workload Identity requires downloading JSON key files, which introduces key management overhead, rotation risks, and potential secret exposure - exactly what Google recommends avoiding.

Workload Identity Federation (D) is the right tool when workloads run outside GCP (e.g., AWS, Azure, on-premises) and need to access GCP APIs without long-lived keys. Since Mountkirk's workloads are already on GKE, federation is unnecessary overhead.

Memory tip: Think of it as a location test - inside GKE → Workload Identity; outside GCP → Workload Identity Federation. The word "Federation" implies crossing a boundary between clouds.

Topics

#GKE Identity#Workload Identity#Cloud Security#IAM Best Practices

Community Discussion

No community discussion yet for this question.

Full PROFESSIONAL-CLOUD-ARCHITECT Practice