A & D Binary Authorization to ensure only verified containers are deployed To ensure deployment are secure and and consistent, automatically scan images for vulnerabilities with container analysis (https://cloud.google.com/docs/ci-cd/overview?hl=en&skip_cache=true)

IMHO its A&C

ad for me

https://cloud.google.com/docs/ci-cd/overview?hl=en&skip_cache=true https://cloud.google.com/binary-authorization/docs/overview

For surę AC

Answer should be A & C, as the ask is to ensure only verified containers to be deployed. With just Binary Authorisation and signing images, you can't fulfil the requirement, you would need to also restrict it at the IAM level, so that no bad actor can create an image in the registry and bypass Binary Authorization to deploy an image.

I think A&B Kritis is an admission controller webhook for Kubernetes that enforces deploy-time security policies. By configuring Jenkins to use Kritis, you can cryptographically sign containers as part of the CI/CD pipeline, ensuring only signed containers are deployed. https://cloud.google.com/binary-authorization/docs/creating-attestations-kritis

Option C is incorrect because while limiting access to trusted service accounts enhances security, it doesn't ensure that only verified containers are deployed.

Checked with standard process for this. I found the below. Image Building and Scanning: Developers build container images locally or using Cloud Build. Images are scanned for vulnerabilities using integrated tools or third-party services. Clean images are pushed to GCR. Image Verification: Binary Authorization enforces policies for image acceptance. Attestations from Cloud Security Scanner or third-party tools can be used.

A&D. C is incorrect because you configuring Container Registry doesn't only allow trusted service accounts to create/deploy containers. With IAM permissions, anyone can create non-trusted service accounts to deploy containers, or users can still deploy containers not in Container Registry.

A & C correct

a and c are ok

Who has untrsuted service accounts that can deploy stuff and is doing nothing about it?. That is bad architecture. Following good architecture design, D is a given, we will already have a limited number of trusted accounts that can deploy. So A and C.

A & D - sounds more native to Google Cloud services and must required.

AD - correct answers. C -- Trusted service accounts ? does not make sense.

Container Registry can allow select trusted services to access a registry that's configured with network access rules. When trusted services are allowed, a trusted service instance can securely bypass the registry's network rules and perform operations such as pull or push images. The best choice is C here

Binary authorization and Service Account controls (as the question is asking on how you would secure the deployment process and not improving the security of the application)