Enforcing Trusted Container Images in GKE

PCSE By islever Editorial Last updated

Managing and implementing authorization controls. Managing encryption at rest, in transit, and in use.

Short answer

CE Create a custom organization policy constraint to enforce Binary Authorization for GKE and configure the Binary Authorization policy with respective attestations for the project.

Question

Your organization is transitioning to Google Cloud. You want to ensure that only trusted container images are deployed on Google Kubernetes Engine (GKE) clusters in a project. The containers must be deployed from a centrally managed Container Registry and signed by a trusted authority.
What should you do? (Choose two.)
  1. Enable Container Threat Detection in the Security Command Center (SCC) for the project.
  2. Configure the trusted image organization policy constraint for the project.
  3. Create a custom organization policy constraint to enforce Binary Authorization for Google Kubernetes Engine (GKE). Correct Answer
  4. Enable PodSecurity standards, and set them to Restricted.
  5. Configure the Binary Authorization policy with respective attestations for the project. Correct Answer

Key Takeaways

The trap is confusing Compute Engine trusted image policies (which restrict disk images) with GKE container image requirements. Binary Authorization is the specific tool for container signature validation, and Org Policy is needed to enforce its use.

To deploy only trusted, signed container images on GKE, you must enforce Binary Authorization via an Organization Policy Constraint and configure attestation policies. This ensures both source restriction and signature verification.

Common mistake: Choosing B and E. Option B (`compute.trustedImageProjects`) applies to Compute Engine VM disk images, not container images stored in Container Registry or Artifact Registry. It cannot restrict GKE workload deployments.

Expert Analysis

The question requires a two-part solution to ensure only trusted container images are deployed on GKE, specifically addressing two distinct constraints: source (centrally managed registry) and integrity (signed by a trusted authority).

Option B, "Configure the trusted image organization policy constraint," refers to the compute.trustedImageProjects constraint. As noted in community comments, this constraint is designed for Compute Engine persistent disk images, not Google Container Registry or Artifact Registry images used in GKE. Therefore, it does not satisfy the requirement to restrict container sources.

Option E, "Configure the Binary Authorization policy with respective attestations for the project," directly addresses the signing requirement. Binary Authorization uses attestations to verify that images are signed by trusted authorities before deployment.

Option C, "Create a custom organization policy constraint to enforce Binary Authorization for Google Kubernetes Engine (GKE)," is the correct mechanism to enforce the use of Binary Authorization at the organizational level. Without this enforcement, Binary Authorization policies might be ignored or disabled by users. This option effectively mandates that all GKE clusters in the project must adhere to the Binary Authorization rules defined in Option E.

Therefore, the combination of enforcing Binary Authorization via Org Policy (C) and configuring the specific attestation/signing rules (E) provides the complete solution. Options A and D relate to threat detection and pod security standards, respectively, which do not control image source or signature validation.

Official Reference

These links open the official vendor documentation in a new tab.

Exam Strategy

When dealing with multi-select questions about security controls, identify the distinct technical requirements. Here, one part is 'enforcement' (Org Policy) and the other is 'validation logic' (Binary Auth Attestations). Always check if a policy constraint is specific to the service; compute. prefixes usually apply to VMs, while containeranalysis or Binary Authorization applies to containers.

Frequently Asked Questions

Why is Option B incorrect for GKE?

Option B configures the compute.trustedImageProjects constraint, which restricts the creation of Persistent Disks from specific projects. It does not apply to container images used in GKE workloads.

What is the role of Binary Authorization attestations?

Attestations provide a verifiable signature from a trusted authority confirming that an image meets certain criteria. Binary Authorization checks these attestations before allowing deployment.

More PCSE FAQ →

Community Votes

E
50%
B
27%
C
23%

50% of anonymous learners picked answer E. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 20 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 20

  1. Xoxoo 👍 4
    To ensure that only trusted container images are deployed on Google Kubernetes Engine (GKE) clusters in a project and that the containers are deployed from a centrally managed Container Registry and signed by a trusted authority, you should consider the following options: Configure the trusted image organization policy constraint for the project (Option B): This will allow you to create an organization policy constraint that enforces the use of only trusted images from a specific Container Registry. You can specify the registry that must be used, ensuring that images are sourced only from that trusted location. Configure the Binary Authorization policy with respective attestations for the project (Option E): Binary Authorization for GKE allows you to create policies that enforce the use of only trusted container images. You can specify which images are trusted and require attestation from trusted authorities before deployment. This ensures that only signed and trusted images can be deployed on the GKE clusters in the project.
  2. pfilourenco 👍 4
    It's C and E. A -> cannot be because it does not make sense for centrally managing images and validating signed images. B -> Cannot be, because that org policy only applies to Compute Disk images, not containers (https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints) C -> Correct,m because we can create custom org policy for GKE to enforce Binary Authorization for image atestation (https://cloud.google.com/kubernetes-engine/docs/how-to/custom-org-policies#enforce) D -> PodSecurity policies are not applicable for this use case E -> We need to configure Binary Authorization in order to setup attestations to only allow specific images to be deployed in the cluster (https://cloud.google.com/binary-authorization/docs/setting-up). So, it's C and E.
  3. gcp4test 👍 3
    B is for Compute Engine images. I think it is CE C - custom constraints for Binary Auth on GKE -OK E - We provide in Binary Auth rule Container Registry from where, we can deploy images
  4. Xoxoo 👍 2
    Options A, C, and D are not directly related to ensuring the use of trusted container images from a centrally managed Container Registry and signed by a trusted authority: A. Enabling Container Threat Detection in Security Command Center (SCC) helps with threat detection but does not directly enforce the use of trusted container images. C. Creating a custom organization policy constraint for Binary Authorization is redundant and unnecessary when Binary Authorization can be configured directly (Option E). D. Enabling PodSecurity standards to a "Restricted" level enforces certain security policies on pods but does not directly address the issue of ensuring trusted container images.
  5. cyberpunk21 👍 2
    B. This policy ensures that only trusted images from specific Container Registry repositories can be deployed. This meets one of the requirements E. Binary Authorization ensures that only container images that are signed by trusted authorities can be deployed on GKE. Attestations are a component of this, as they provide a verifiable signature by trusted parties that an image meets certain criteria.
Show 15 more comments
  1. JohnDohertyDoe 👍 2
    It cannot be B, because the trusted image policy does not support container images (it is used for Compute Engine images). Use the Trusted image feature to define an organization policy that allows principals to create persistent disks only from images in specific projects. https://cloud.google.com/compute/docs/images/restricting-image-access
  2. K1SMM 👍 2
    BC is correct answer
  3. Bettoxicity 👍 2
    BE are correct!
  4. Mithung30 👍 2
    CE is correct
  5. akg001 👍 2
    C and E
  6. ArizonaClassics 👍 1
    To ensure that only trusted container images are deployed on Google Kubernetes Engine (GKE) clusters in a project and that these containers are deployed from a centrally managed Container Registry and signed by a trusted authority, you should consider the following two actions: B. Configure the trusted image organization policy constraint for the project. Trusted image sources can be specified at the project level using organization policy constraints. This ensures that only images from trusted Container Registries can be deployed. E. Configure the Binary Authorization policy with respective attestations for the project. Binary Authorization allows you to specify a policy that will require images to be signed by trusted authorities before they can be deployed. You can configure this with attestations to indicate that certain steps, like vulnerability scanning and code reviews, have been completed.
  7. p981pa123 👍 1
    The option B. Configure the trusted image organization policy constraint for the project is not directly applicable to Google Kubernetes Engine (GKE) in the way that Binary Authorization is. Instead, this option refers to configuring an organization policy that ensures that only trusted images are used across all services, but it doesn't directly enforce a signature or attestation policy for images in GKE clusters. This organization policy is more about restricting sources of images (e.g., only allowing images from specific container registries), but it doesn't directly involve GKE enforcement of trust policies.
  8. arpgaur 👍 1
    B and E. This will create a policy that enforces Binary Authorization and specifies that only images from the centrally managed Container Registry can be deployed. C and E. This will create a policy that enforces Binary Authorization and specifies that only images that are signed by a trusted authority can be deployed. However, it does not specify the source of the images.
  9. cyberafrica89 👍 1
    trusted image policies can and are often used to manage and enforce security standards for container images. These policies help ensure that only trusted images, which have been verified and potentially signed, are deployed to environments. This is a crucial security practice for preventing vulnerabilities and ensuring the integrity of container deployments.
  10. oezgan 👍 1
    https://cloud.google.com/compute/docs/images/restricting-image-access "Enact an image access policy by setting a compute.trustedImageProjects constraint on your project, your folder, or your organization."
  11. STomar 👍 1
    Correct Answer: BE B: Configure the trusted image organization policy constraint for the project. E: Configure the Binary Authorization policy with respective attestations for the project.
  12. irmingard_examtopics 👍 1
    C is unnecessary because Binary Authorization is natively available and does not require creating a custom organization policy constraint from scratch.
  13. desertlotus1211 👍 1
    What is the 'trusted image organization policy constraint'? Where is it defined and found? Can someone provide it?
  14. cyberpunk21 👍 1
    it's an org policy constraint it applies to all kings of images
  15. pradoUA 👍 1
    BE are correct

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

How to Implement TLS Interception for On-Premise Traffic in GCP

S-grade

How to Secure Vertex AI Training Jobs with Regional CMEK?

S-grade

Integrating On-Premises Active Directory with Google Cloud IAM

S-grade

Cloud External Key Manager and Confidential VM Implementation Constraints

S-grade

← Back to PCSE Study Guide