An enterprise DevOps team manages deployment pipelines for microservices running across development, staging, and production namespaces in a Cloud Service Mesh on Google Kubernetes Engine (GKE). To satisfy strict security and compliance standards, the team must implement environment-aware access controls: In production, services must only accept traffic from workloads authenticated with the specific production service account identity (spiffe://cluster.local/ns/prod/sa/prod-runner-sa). Plaintext or unauthenticated requests with empty principal identities must be rejected immediately. The security model in production must enforce least privilege and deny all unauthorized communication by default. Which Cloud Service Mesh policy strategy should the team implement in the production namespace?

Deploy an AuthorizationPolicy with action ALLOW scoped to the workload selector that explicitly matches the prod-runner-sa principal under rules.from.source.principals, combined with STRICT mutual TLS (mTLS) or a DENY policy matching notPrincipals: ["*"].: ### What Cloud Service Mesh Authorization Policies Are An **AuthorizationPolicy** in Cloud Service Mesh (built on Istio) provides fine-grained, declarative access control for workloads at the service mesh layer. It allows administrators to enforce identity-based access control policies using authenticated service account identities across different namespaces and environments. By combining workload selectors, source identity verification (`principals`), and transport-level security, Cloud Service Mesh enforces the principle of least privilege. ### How It Meets the Requirements - **Production Identity Restriction**: The policy explicitly sets `action: ALLOW` and defines `rules.from.source.principals` with the SPIFFE identity corresponding to `prod-runner-sa`. Only workloads authenticated with that specific service account identity are granted access. - **Rejecting Plaintext & Unauthenticated Requests**: When combined with **STRICT mTLS** or an explicit `DENY` policy matching `notPrincipals: ["*"]`, requests lacking a validated cryptographic identity (such as plaintext requests with empty principal headers) are denied before reaching the application. - **Least Privilege Default-Deny**: In Cloud Service Mesh, when an `ALLOW` policy is applied to a workload, an implicit default-deny rule is enforced. Any traffic not matching the specified rules and principals is automatically denied. ### Key Advantages and Capabilities - **Cryptographic Identity Validation**: Enforces authentication at the transport layer using short-lived X.509 certificates. - **Namespace and Environment Isolation**: Confines granular write/execute permissions to dedicated service accounts in the production environment. - **Declarative Policy as Code**: Allows authorization configurations to be version-controlled, tested in CI/CD pipelines, and rolled out per environment. - **Hierarchical Precedence**: Evaluates explicit `DENY` policies before `ALLOW` policies to guarantee security guardrails. ### Why This Is Optimal This approach directly leverages Cloud Service Mesh's identity extraction and policy engine. It guarantees that development and staging identities cannot invoke production workloads, and that unauthenticated or unapproved principals are rejected by default.

Cloud Service Mesh Environment Iam Authorization Policy | Professional Cloud DevOps Engineer

Cloud Service Mesh Environment Iam Authorization Policy

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

An enterprise DevOps team manages deployment pipelines for microservices running across development, staging, and production namespaces in a Cloud Service Mesh on Google Kubernetes Engine (GKE). To satisfy strict security and compliance standards, the team must implement environment-aware access controls:

In production, services must only accept traffic from workloads authenticated with the specific production service account identity (spiffe://cluster.local/ns/prod/sa/prod-runner-sa).
Plaintext or unauthenticated requests with empty principal identities must be rejected immediately.
The security model in production must enforce least privilege and deny all unauthorized communication by default.

Which Cloud Service Mesh policy strategy should the team implement in the production namespace?

Deploy an AuthorizationPolicy with action ALLOW scoped to the workload selector that explicitly matches the prod-runner-sa principal under rules.from.source.principals, combined with STRICT mutual TLS (mTLS) or a DENY policy matching notPrincipals: ["*"].

Grant the Google Cloud predefined role roles/container.serviceAgent directly to developer human identities and the prod-runner-sa service account at the production project level.

Configure an AuthorizationPolicy with action DENY containing an empty spec (allow-nothing) and assign developers the roles/iam.securityAdmin role to bypass mesh enforcement.

Deploy an AuthorizationPolicy configured with action ALLOW and an empty rules list (rules: - {}), and rely on standard Kubernetes NetworkPolicies to filter source IP addresses.

Professional Cloud DevOps Engineer

Cloud Service Mesh Environment Iam Authorization Policy

Related questions