A new platform team is onboarding 40 microservices owned by five product teams into HCP Terraform. Each service has dev and prod, every team must manage only its own services, and shared credentials and policies should be applied per team rather than per service. How should the hierarchy be laid out?
Select an answer to reveal the explanation.
Short Explanation
Picture a building: the organization is the building, projects are floors for each team, and workspaces are the individual offices. Hand each team its own floor and you can set keys, shared supplies and rules once per floor.
Full Explanation
HCP Terraform organizes resources as organization, then project, then workspace. The organization is the top-level boundary for users, teams, VCS connections, policy sets and billing. Projects group related workspaces, and teams can be granted project-level roles that apply to every current and future workspace in the project; projects can also own variable sets and be targets for policy sets and auto-destroy defaults. Workspaces hold the state, variables and run history for one configuration instance, so a workspace per service per environment keeps each state small and independently runnable. A project per product team therefore matches the stated ownership and lets credentials and policies be applied per team. An organization per service multiplies administration and splits governance, because policy sets, teams and SSO settings would have to be repeated in 40 places. The hierarchy runs the other way: projects contain workspaces, and a workspace cannot contain projects. A single workspace with -target per team couples every service into one state and one lock, and resource targeting is an exceptional tool rather than an operating model. Exam caveat: project-level permissions do not grant organization-wide abilities such as managing policy sets. Operational check: after setup, sign in as a member of one product team and confirm only that team's project and workspaces are visible.