Configuring Access and Security
What this domain tests
Security questions test least privilege, identity, and data protection. You should be fluent in IAM roles, service accounts, and encryption options, and know how policy inheritance affects effective access.
Concepts to master
- IAM model. Permissions bundle into roles; roles are granted to principals (users, groups, service accounts) at a resource node. Predefined roles are usually safer than primitive owner/editor roles. Effective permission is the union of grants along the hierarchy.
- Service accounts. Workloads should use dedicated service accounts with narrow roles, ideally with short-lived credentials rather than downloaded keys. Key files are a long-lived risk.
- Network and data controls. Firewall rules, private connectivity, and encryption at rest and in transit protect data. Customer-managed keys give control over rotation and revocation.
- Auditing. Audit logs record admin activity and data access; they support investigations and compliance.
Traps to expect
Common traps: assuming a grant at a folder can be removed at a project (deny and allow combine by union, so you must remove the higher-level grant); confusing a role with a permission; and assuming encryption at rest is optional (it is default). Another trap is granting primitive roles for convenience, which violates least privilege.
Rule of thumb
Grant to groups, not individuals, at the highest node that covers the need, using predefined roles. Worked example: an application reading from object storage should run as a dedicated service account bound to an object-viewer role on the specific bucket, not project editor - this limits blast radius if the workload is compromised.