Instiq
Chapter 1 · Designing cloud-native applications·v1.0.0·Updated 6/15/2026·~15 min

What's changed: Created Professional Cloud Developer Chapter 1 (Domain 1 "Design" part 1: high-performing apps/APIs = CE/GKE/Cloud Run/Functions, LB/session affinity, Memorystore, REST/gRPC, Apigee/API Gateway, Pub/Sub/Eventarc/Cloud Tasks/Workflows, traffic splitting; secure apps = Secret Manager/Cloud KMS, service accounts/Workload Identity Federation/ADC, least privilege, IAP, Binary Authorization, Artifact Analysis/SCC, Cloud Service Mesh).

1.2Designing secure applications

Key points

Understand managing secrets and keys (Secret Manager, Cloud KMS), authentication via service accounts and Workload Identity Federation, least-privilege IAM, protection with Identity-Aware Proxy (IAP), artifact verification with Binary Authorization, and secure service-to-service communication.

Cloud-native apps must be built securely. Developers bake secret handling, authentication, least privilege, and artifact trust into the design.

1.2.1Secrets, keys, and authentication

Store secrets (API keys, passwords) in Secret Manager—never embed them in code. Manage encryption keys with Cloud KMS. Authenticate apps with service accounts, and from external identities (other clouds/on-prem/CI) federate securely with Workload Identity Federation instead of distributing keys. Authenticate to Google Cloud via Application Default Credentials (ADC) by default. Map "secrets = Secret Manager," "app permissions = service account + least privilege," and "do not distribute keys = Workload Identity Federation."

1.2.2Protection and artifact trust

Protect app access by identity with Identity-Aware Proxy (IAP), exposing apps securely without a VPN. Design IAM with least privilege (avoid basic roles; predefined/custom). Sign and verify deployed container images with Binary Authorization, allowing only trusted artifacts onto GKE/Cloud Run. Detect/address vulnerabilities with Artifact Analysis and Security Command Center. Secure service-to-service traffic with Cloud Service Mesh or network policies. Map "identity-based access protection = IAP" and "allow only trusted images = Binary Authorization."

Exam point

Common: requirement → means. E.g., "store API keys/passwords safely" = Secret Manager; "auth from external identity without embedding keys" = Workload Identity Federation; "identity-based app protection" = IAP; "deploy only trusted images" = Binary Authorization; "permissions for an app" = service account + least privilege.

Warning

Watch the mix-ups: (1) Do not embed secrets in code/images—use Secret Manager. (2) Avoid distributing SA keys; prefer Workload Identity Federation/short-lived credentials. (3) IAP (identity-based access) and Binary Authorization (artifact trust) are different defenses.

Diagram of Secret Manager/Cloud KMS, service accounts/Workload Identity Federation/ADC, IAP, Binary Authorization, and Artifact Analysis/SCC.
Build securely

1.2.3Section summary

  • Secrets = Secret Manager, keys = Cloud KMS, auth = service accounts/ADC/Workload Identity Federation
  • Protect apps by identity with IAP; IAM least privilege
  • Binary Authorization allows only trusted images; vulnerabilities via Artifact Analysis/SCC

Sign in to track progress — Log in.

Quick check

(just a quick review)

Q1. To store/retrieve API keys and passwords securely without embedding them in code, which is best?

Q2. To authenticate to Google Cloud from CI or other-cloud external identities without distributing SA keys, which is best?

Q3. To protect access to an internal app by identity without a VPN, which is best?

Q4. To allow only trusted (signed) container images onto GKE/Cloud Run, which is best?

Q5. Which principal best grants permissions to an application (workload)?

Q6. To detect vulnerabilities in container images around deployment, which is best?

Check your understandingPractice questions for Chapter 1: Designing cloud-native applications