Binary Authorization Attestor Implementation
Short answer
C Enable Binary Authorization on the GKE cluster, create a Cloud KMS keyring and attestor, and use the key to create an attestation after the build.
Question
Key Takeaways
The exam tests the complete lifecycle of Binary Authorization, revealing the common trap of skipping the infrastructure setup (KMS key, attestor creation) and image signing steps required before policies can function.
This question addresses securing GKE deployments using Binary Authorization and Cloud KMS attestors to ensure only pipeline-built images are deployed. It establishes that creating the attestor and signing images is a prerequisite for policy enforcement.
Common mistake: Option D is the most frequent incorrect choice because it assumes the attestor exists or that configuring the policy alone is sufficient, ignoring the operational requirement to sign images with the created key.
Expert Analysis
Why the Answer Is Correct
Option C is correct because it provides the complete, minimal-effort solution for implementing attestation. It involves enabling Binary Authorization, setting up the necessary cryptographic identity (Cloud KMS keyring and attestor), and integrating the signing process into the CI/CD pipeline (implied by 'After Cloud Build pushes...'). Without the key and the actual signature, no image can be verified.Why the Other Options Are Wrong
Option A suggests using Cloud Run functions for verification, which adds unnecessary manual maintenance and complexity compared to native Binary Authorization integration. Option B restricts push access but does not prevent an attacker from pushing directly or bypassing controls if permissions change; it also doesn't leverage the specific 'built-by-cloud-build' attestor concept. Option D configures the policy but fails to create the attestor or sign the images, rendering the policy useless as no valid attestations would exist.Community Comment Notes
Commenters emphasized that D is a trap, noting that "imply updating the Binary Authorization policy without creating the Cloud KMS key... will cause all deployments to fail". The consensus highlights that the physical/digital assets (key, attestor, signature) must exist before the policy can enforce them.Exam Strategy
Always verify that the prerequisites for a security control (like keys, certificates, or identities) are explicitly included in the answer option. In PCDOE questions about 'secure deployment', look for options that cover both the configuration of the guardrail and the implementation of the mechanism being guarded.
Frequently Asked Questions
Why is Option D insufficient for Binary Authorization?
Does Binary Authorization require manual intervention?
Discussion 2 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 2
-
nbeeckx 👍 1 Answered CD is incorrect. imply updating the Binary Authorization policy without creating the Cloud KMS key, configuring the attestor, and signing the built images via Cloud Build will cause all deployments to fail because no valid attestations exist for Binary Authorization to verify.
-
rage99 👍 1 Answered DD. Enable Binary Authorization on the GKE cluster. Configure the Binary Authorization policy to require the projects/PROJECT_ID/attestors/built-by-cloud-build attestor.
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.
Related Analysis
Practice All PCDOE Questions
Access 75 questions with complete answers and detailed explanations.
View Full PCDOE Practice Test →