PCA Failed Topics for Review Flashcards
Where can you set an IAM policy on a resource?
You can set an IAM policy at the organization level, the folder level, the project level, or (in some cases) the resource level.
Resources inherit the policies of the parent resource. If you set a policy at the organization level, it is inherited by all its child folder and project resources, and if you set a policy at the project level, it is inherited by all its child resources.
What happens to inherited resource permissions when you move a project to a new location?
IAM policy hierarchy follows the same path as the Google Cloud resource hierarchy. If you change the resource hierarchy, the policy hierarchy changes as well.
moving a project resource from one folder resource to another will change the inherited permissions. Permissions that were inherited by the project resource from the original parent resource will be lost when the project resource is moved to a new folder resource. Permissions set at the destination folder resource will be inherited by the project resource as it is moved.
What types of users can create an organization resource?
Google Workspace and Cloud Identity customers can create organization resources.
Each Google Workspace or Cloud Identity account is associated with one organization resource.
When an organization resource exists, it is the top of the Google Cloud resource hierarchy, and all resources that belong to an organization are grouped under the organization resource.
What pre - requisites are required to create folder resources?
An organization resource is required as a prerequisite to use folders. Folder resources and their child project resources are mapped under the organization resource.
What is the benefit of having Google Cloud organization and folder resources?
organization resource and folder resources, allows companies to map their organization onto Google Cloud.
These provide logical attachment points for access management policies (IAM) and Organization policies.
Are Orgnization resources required for Google Cloud?
Google Cloud users are not required to have an organization resource, but some features of Resource Manager will not be usable without one.
The organization resource is closely associated with a Google Workspace or Cloud Identity account.
When a user with a Google Workspace or Cloud Identity account creates a Google Cloud project resource, an organization resource is automatically provisioned for them.
What restrictions with a managed user (workspace or cloud identity) when they create a project?
If a user specifies an organization resource and they have the right permissions, the project is assigned to that organization.
Otherwise, it will default to the organization resource the user is associated with.
What happens when you adopt Cloud Identity for an IAM heirarchy.
When you adopt Cloud Identity, you create a Cloud Identity account for each of your users and groups.
You can then use Identity and Access Management (IAM) to manage access to Google Cloud resources for each Cloud Identity account.
Are you able to migrate projects from one organization to another?
Yes - must check services and see what is allowed with project resources?
Need IAM Permissions to move project resource
If need be, can change back
Use import and export folders
Where can you set an IAM Policy?
You can set an IAM policy at the organization level, the folder level, the project level, or (in some cases) the resource level.
Resources inherit the policies of the parent resource.
If you set a policy at the organization level, it is inherited by all its child folder and project resources, and if you set a policy at the project level, it is inherited by all its child resources.
Can you remove a permission that was granted at a higher level resource?
Roles are always inherited, and there is no way to explicitly remove a permission for a lower-level resource that is granted at a higher level in the resource hierarchy.
If you change the Google Cloud Resource Heirarchy, what happens to the policy Heirarchy?
The IAM policy hierarchy follows the same path as the Google Cloud resource hierarchy. If you change the resource hierarchy, the policy hierarchy changes as well. For example, moving a project into an organization resource will update the project’s IAM policy to inherit from the organization resource’s IAM policy.
What happens when a project moves from one folder resource to another?
Moving a project resource from one folder resource to another will change the inherited permissions. Permissions that were inherited by the project resource from the original parent resource will be lost when the project resource is moved to a new folder resource. Permissions set at the destination folder resource will be inherited by the project resource as it is moved.
How do you use projects for organizing resources?
Use projects to group resources that share the same trust boundary. For example, resources for the same product or microservice can belong to the same project.
Why should you audit your allow policies?
Audit your allow policies to ensure compliance. Audit logs contain all setIamPolicy() calls, so you can trace when an allow policy has been created or modified.
Audit the ownership and the membership of the Google groups used in allow policies.
How do you limit project creation in your organization?
If you want to limit project creation in your organization, change the organization policy to grant the Project Creator role to a group that you manage.
Remove the default roles for project creation that are setup by default.
What are the benefits of the Organization Policy Service?
Centralize control to configure restrictions on how your organization’s resources can be used.
Define and establish guardrails for your development teams to stay within compliance boundaries.
Help project owners and their teams move quickly without worry of breaking compliance.
What are common use cases for the organization policies?
Organization policies are made up of constraints that allow you to:
Limit resource sharing based on domain.
Limit the usage of Identity and Access Management service accounts.
Restrict the physical location of newly created resources.
What are the Differences from Identity and Access Management and Organization Policy Service?
Identity and Access Management focuses on who, and lets the administrator authorize who can take action on specific resources based on permissions.
Organization Policy focuses on what, and lets the administrator set restrictions on specific resources to determine how they can be configured.
What is a constraint for an organization policy service?
A constraint is a particular type of restriction against a Google Cloud service or a list of Google Cloud services. Think of the constraint as a blueprint that defines what behaviors are controlled. This blueprint is then applied to a resource hierarchy node (folder, project, or org) as an organization policy, which implements the rules defined in the constraint. The Google Cloud service mapped to that constraint and associated with that resource hierarchy node will then enforce the restrictions configured within the organization policy.
What are the different storage classes for any workload?
Storage classes for any workload
Save costs without sacrificing performance by storing data across different storage classes. You can start with a class that matches your current use, then reconfigure for cost savings.
Standard Storage: Good for “hot” data that’s accessed frequently, including websites, streaming videos, and mobile apps.
Nearline Storage: Low cost. Good for data that can be stored for at least 30 days, including data backup and long-tail multimedia content.
Coldline Storage: Very low cost. Good for data that can be stored for at least 90 days, including disaster recovery.
Archive Storage: Lowest cost. Good for data that can be stored for at least 365 days, including regulatory archives.
What are the different persistent disk types?
Standard persistent disks (pd-standard) are backed by standard hard disk drives (HDD).
Balanced persistent disks (pd-balanced) are backed by solid-state drives (SSD). They are an alternative to SSD persistent disks that balance performance and cost.
SSD persistent disks (pd-ssd) are backed by solid-state drives (SSD).
Extreme persistent disks (pd-extreme) are backed by solid-state drives (SSD). With consistently high performance for both random access workloads and bulk throughput, extreme persistent disks are designed for high-end database workloads. Unlike other disk types, you can provision your desired IOPS. For more information, see Extreme persistent disks.
How can you protect against data loss on persistent disks?
you can create snapshots of persistent disks to protect against data loss due to user error. Snapshots are incremental, and take only minutes to create even if you snapshot disks that are attached to running instances.
What are the 6 steps to setup a cloud solution?