You want to limit the images that can be used as the source for boot disks. These images will be stored in a dedicated project. What should you do?
A.
Use the Organization Policy Service to create a compute.trustedimageProjects constraint on the organization level. List the trusted project as the whitelist in an allow operation.
B.
Use the Organization Policy Service to create a compute.trustedimageProjects constraint on the organization level. List the trusted projects as the exceptions in a deny operation.
C.
In Resource Manager, edit the project permissions for the trusted project. Add the organization as member with the role: Compute Image User.
D.
In Resource Manager, edit the organization permissions. Add the project ID as member with the role: Compute Image User.
Correct Answer is: A. Option B suggests listing the trusted projects as exceptions in a deny operation, which is not necessary or recommended. It's simpler and more secure to explicitly allow only the trusted project
To limit the images that can be used as the source for boot disks and store these images in a dedicated project, you should use option A:
A. Use the Organization Policy Service to create a compute.trustedimageProjects constraint on the organization level. List the trusted project as the whitelist in an allow operation.
Here's why this option is appropriate:
Organization-Wide Control: Creating an organization-level constraint allows you to enforce the policy organization-wide, ensuring consistent image usage across all projects within the organization.
Whitelist Approach: By listing the trusted project as a whitelist in an "allow" operation, you explicitly specify which project can be trusted as the source for boot disks. This is a more secure approach because it only allows specific trusted projects.
Dedicated Project: You mentioned that the images are stored in a dedicated project, and this option aligns with that requirement.
Option B introduces complexity by listing the trusted projects as exceptions in a "deny" operation, which can become challenging to manage as more projects are added.
Actually the default policy is allow * and if you put a constraint it must be as "deny" rule with exceptionsPrincipals or denial conditions. So answer is B, there's no "whitelist".
A is right
Use the Trusted image feature to define an organization policy that allows principals to create persistent disks only from images in specific projects.
Answer A. Use the Organization Policy Service to create a compute.trustedimageProjects constraint on the organization level. List the trusted project as the whitelist in an allow operation.
To me the answer seems to be B.
https://cloud.google.com/compute/docs/images/restricting-image-access
By default, instances can be created from images in any project that shares images publicly or explicitly with the user. So there is an implicit allow.
Option B states that we need to deny all the projects from being used as a trusted project and add "Trusted Project" as an exception to that rule.
Answer is A.
"Use the Trusted image feature to define an organization policy that allows your project members to create persistent disks only from images in specific projects."
"After sharing your images with other users, you can control where those users employ those resources within your organization. Set the constraints/compute.storageResourceUseRestrictions constraint to define the projects where users are permitted to use your storage resources."
A voting comment increases the vote count for the chosen answer by one.
Upvoting a comment with a selected answer will also increase the vote count towards that answer by one.
So if you see a comment that you already agree with, you can upvote it instead of posting a new comment.
DebasishLowes
Highly Voted 3 years, 7 months ago[Removed]
Highly Voted 4 years agonccdebug
Most Recent 8 months, 2 weeks agoXoxoo
1 year, 1 month agoXoxoo
1 year, 1 month agoJoanale
1 year, 4 months agomeh009
1 year, 11 months agoAzureDP900
1 year, 12 months agoAzureDP900
1 year, 12 months agoAwesomeGCP
2 years agopiyush_1982
2 years, 3 months agopiyush_1982
2 years, 3 months agosimbu1299
2 years, 7 months agodanielklein09
2 years, 7 months agogcpengineer
1 year, 5 months agoCHECK666
4 years, 1 month agoownez
4 years, 2 months agoownez
4 years, 2 months agoSheeda
4 years, 2 months ago