Examtopics

. Treat each component of your application as a separate trust boundary. If you have multiple services that requires different permissions, create a separate service account for each of the services so that they can be permissioned differently. . Grant primitive roles in the following cases: .when the Cloud Platform service does not provide a predefined role. See the predefined roles table for a list of all available predefined roles. .when you want to grant broader permissions for a project. This often happens when youre granting permissions in development or test environments. .when you need to allow a member to modify permissions for a project, youll want to grant them the owner role because only owners have the permission to grant access to other users for projects. .when you work in a small team where the team members dont need granular permissions. . Remember that a policy set on a child resource cannot restrict access granted on its parent. Check the policy granted on every resource and make sure you understand the hierarchical inheritance. . Grant roles at the smallest scope needed. For example, if a user only needs access to publish Pub/Sub topic, grant the Publisher role to the user for that topic. . Restrict who can act as service accounts. Users who are granted the Service Account Actor role for a service account can access all the resources for which the service account has access. Therefore be cautious when granting the Service Account Actor role to a user. Restrict who has access to create and manage service accounts in your project. . Granting owner role to a member will allow them to modify the IAM policy. Therefore grant the owner role only if the member has a legitimate purpose to manage the IAM policy. This is because as your policy contains sensitive access control data and having a minimal set of users manage it will simplify any auditing that you may have to do. Reference: https://cloud.google.com/iam/docs/using-iam-securely