Every large AWS organization runs into the same tension: developers want to provision infrastructure fast, and the platform team wants every resource provisioned safely — approved configurations, least-privilege permissions, consistent tags, the right accounts. Hand developers AdministratorAccess and you get speed with no guardrails. Lock everything behind a ticket queue and you get governance with no agility. AWS Service Catalog is the service the SAP-C02 expects you to reach for when a scenario describes exactly this problem: self-service provisioning within guardrails.
Service Catalog rarely gets a dedicated study session, yet it shows up in the exam’s organizational-complexity and governance scenarios precisely because it resolves that speed-versus-control conflict in a way no other single service does. This guide covers the pieces the exam tests — portfolios, products, the constraint types, TagOptions, Organizations sharing, and how it slots in beside CloudFormation, StackSets and Control Tower. For the broader account structure it plugs into, keep the multi-account architecture guide nearby, and for the exam as a whole, the SAP-C02 study guide.
The Problem Service Catalog Solves
Think about what “let a team deploy a compliant RDS database” actually requires if you do it with raw IAM. The developer needs permission to create RDS instances, subnet groups, parameter groups, security groups, KMS grants, and more — a wide, dangerous blast radius, and no guarantee they pick approved settings. Multiply that across dozens of resource types and dozens of teams and governance collapses.
Service Catalog inverts the model. The platform team authors an approved product once — say, “Standard Encrypted RDS (MySQL, Multi-AZ)” — bakes in the compliant settings, and publishes it. End users then launch that product from a self-service portal without holding the underlying permissions at all. They get agility; the organization keeps control. That single idea — provisioning decoupled from the provisioner’s permissions — is the heart of every Service Catalog exam question.
Exam signal: “developers should provision approved resources without broad IAM permissions”, “central IT defines standardized/approved configurations that teams deploy themselves”, “self-service within guardrails”, or “enforce consistent tagging on provisioned resources” → AWS Service Catalog.
The Building Blocks: Products and Portfolios
Two objects form the core of Service Catalog, and the exam assumes you can describe both.
A product is a deployable IT service, defined by an infrastructure-as-code template — most commonly an AWS CloudFormation template, with support for Terraform-based products as well. A product is versioned: you publish “v1.0”, later add “v1.1”, and users can be steered to a specific version. The template is where the approved, compliant configuration lives — encryption on, correct instance families, hardened defaults.
A portfolio is a collection of products bundled with the governance around them: who can access it, and which constraints apply. Access is granted by associating IAM principals — roles, users, or groups — with the portfolio. Portfolios are also the unit of sharing across accounts and the Organization.
| Object | What it is | What it carries |
|---|---|---|
| Product | A deployable service (a CloudFormation/Terraform template) | Versions; the approved configuration |
| Portfolio | A bundle of products | Access grants (IAM principals) + constraints + TagOptions |
| Provisioned product | A running instance a user launched | The actual deployed stack/resources |
The flow: admin creates products → groups them into a portfolio → applies constraints → grants access → shares the portfolio → end users browse and launch, producing provisioned products they can update or terminate within the rules.
Constraints: Where the Governance Actually Lives
Products define what can be deployed; constraints define how. This is the most exam-relevant area, because the constraint types map directly to specific governance requirements.
| Constraint | What it does | Scenario it answers |
|---|---|---|
| Launch | Assigns an IAM role that Service Catalog assumes to provision the product | ”Users must launch this without holding the underlying permissions” |
| Template | Rules that restrict the parameter values a user may choose | ”Only allow approved instance types / CIDR ranges” |
| Notification | Sends stack events to an SNS topic | ”Notify a team when a product is launched or fails” |
| StackSet | Provisions the product across multiple accounts and Regions | ”Deploy this baseline to every account in the OU” |
| Tag Update | Controls whether users may change tags on provisioned products | Governing post-launch tag mutability |
The launch constraint is the one to know cold. It is what makes least-privilege self-service possible: you attach an IAM role with exactly the permissions needed to build the product, and Service Catalog uses that role to do the provisioning. The end user only needs permission to launch the product, not to touch RDS, EC2, or KMS directly. If an exam scenario stresses “developers should not have direct permissions to the resources being created”, the answer is a launch constraint with a provisioning role.
Template constraints handle the “approved values only” requirement — for example, restricting an instance-type parameter to a short allowed list so no one launches an oversized instance. They shape the parameters a user sees and validates against them at launch time.
TagOptions: Enforcing Consistent Tagging
A recurring governance pain in large orgs is inconsistent tagging, which wrecks cost allocation and attribution. Service Catalog addresses it with TagOptions — a library of allowed tag key–value pairs managed by administrators and associated with portfolios or products. When a user launches a product, TagOptions govern the tags applied, ensuring every provisioned resource carries the organization’s required, consistent tags (cost center, environment, owner). If a scenario ties Service Catalog to cost allocation or standardized tagging across teams, TagOptions is the mechanism. For how tagging feeds the wider cost model, see the SAP-C02 cost optimization guide.
Sharing Portfolios Across an Organization
In a multi-account world you author products once and distribute them widely. Service Catalog supports two sharing paths:
- Account-to-account sharing: share a portfolio with specific target account IDs. The receiving account imports the shared portfolio and grants its own local principals access.
- AWS Organizations sharing: share a portfolio with the entire Organization or with specific Organizational Units (OUs). New accounts that join a shared OU can automatically receive the portfolio, which is how you keep a growing organization consistent without per-account manual work.
A subtle but testable point: sharing a portfolio shares its products and constraints, but the launch constraint’s IAM role must be resolvable in the consuming account. This is why baseline provisioning roles are typically deployed to every account (often via StackSets) so shared products can launch cleanly everywhere. The identity federation and centralized access guide covers how principals in those accounts get their access in the first place.
Where Service Catalog Fits: The Decision
The exam loves to make you distinguish Service Catalog from its neighbours. They solve different layers of the same “governance at scale” problem and are frequently combined.
| Service | Layer it operates at | Choose it when… |
|---|---|---|
| CloudFormation | Raw infrastructure as code | You need to define infrastructure; no portal, catalog, or per-user guardrails by itself |
| Service Catalog | Governed self-service on top of IaC | Teams should self-provision approved products without broad permissions |
| StackSets | Multi-account/multi-Region deployment of stacks | You (central team) push the same stack to many accounts — not end-user self-service |
| Control Tower | Landing zone + account-level governance | You need a governed multi-account environment with guardrails and account provisioning |
The relationships matter more than the boundaries:
- Service Catalog is built on CloudFormation. A product is a template. Service Catalog adds the catalog, versioning, access control, constraints, and self-service portal that raw CloudFormation lacks.
- Control Tower’s Account Factory uses Service Catalog under the hood. When Control Tower provisions a new account, it does so as a Service Catalog product. So “standardized, self-service account creation” points to Control Tower Account Factory; “standardized, self-service resource provisioning” points to Service Catalog directly. Getting that account-versus-resource distinction right is a common exam differentiator. The multi-account architecture guide covers Control Tower in depth.
- StackSet constraints let Service Catalog deploy across accounts, blending the two so a self-service launch can fan out to many accounts and Regions.
A Worked Exam-Style Scenario
“A company with 40 AWS accounts under Organizations wants application teams to deploy a standardized, encrypted data pipeline themselves. Teams must not have direct permissions to the underlying services, every deployed resource must carry a cost-center tag, and the platform team wants to be notified of each deployment. What should the solutions architect implement?”
Walk the requirements to the mechanisms:
- Standardized, self-service deployment → a Service Catalog product (CloudFormation template with the compliant pipeline).
- No direct permissions to underlying services → a launch constraint with a provisioning IAM role.
- Mandatory cost-center tag → TagOptions on the portfolio.
- Notify the platform team → a notification constraint to an SNS topic.
- Reach all 40 accounts → share the portfolio via Organizations/OUs, with provisioning roles present in each account.
That mapping — requirement to constraint — is exactly the reasoning the SAP-C02 rewards. For the security-perimeter side of these scenarios, pair this with SCPs and Resource Control Policies, which cap what any principal (including a provisioning role) can do organization-wide.
Common Service Catalog Traps on the SAP-C02
- Confusing Service Catalog with Control Tower Account Factory. Service Catalog provisions resources; Account Factory (which is built on Service Catalog) provisions accounts. Read the scenario for “resource” versus “account”.
- Forgetting the launch constraint. Without it, end users need the underlying resource permissions themselves — defeating the whole point. “No direct permissions” ⇒ launch constraint + role.
- Reaching for StackSets when the ask is self-service. StackSets is central-team push; Service Catalog is end-user pull. If the scenario says teams provision themselves, it’s Service Catalog (possibly with a StackSet constraint).
- Ignoring the provisioning role in shared accounts. A shared product won’t launch if its launch-constraint role isn’t resolvable in the consuming account.
- Treating it as raw IaC. Service Catalog’s value is the governance layer — constraints, access control, TagOptions — not the template itself.
How to Study This for the Exam
Service Catalog is a “recognize the pattern and map to the mechanism” topic more than a hands-on one for SAP-C02. Drill the constraint types until each maps instantly to a governance requirement, and keep the Service-Catalog-vs-Control-Tower-vs-StackSets distinction sharp. Then test it under exam conditions: Sailor’s SAP-C02 Certification-Ready Mock Exam Bundle presents governance-at-scale scenarios the way the real exam does — multi-requirement questions where Service Catalog, Organizations, and Control Tower have to be told apart under time pressure. That reasoning-under-constraints practice is what turns a topic you recognize into one you answer correctly.
Frequently Asked Questions
What is AWS Service Catalog used for?
Service Catalog lets organizations create and manage catalogs of approved IT services (products) that end users can deploy in a self-service way, within guardrails. It decouples provisioning from the provisioner’s permissions: the platform team defines compliant, versioned products, and users launch them without holding the underlying IAM permissions.
What is the difference between a portfolio and a product in Service Catalog?
A product is a single deployable service defined by a CloudFormation (or Terraform) template, with versions. A portfolio is a collection of products bundled with governance — the IAM principals allowed to access it, the constraints that apply, and TagOptions. You grant access and share at the portfolio level.
How does a launch constraint work?
A launch constraint assigns an IAM role that Service Catalog assumes to provision a product. End users only need permission to launch the product; the provisioning role holds the permissions to create the actual resources. This enables least-privilege, self-service provisioning where users never touch the underlying services directly.
Service Catalog vs CloudFormation — when do I use each?
CloudFormation defines infrastructure as code but has no built-in catalog, per-user access control, constraints, or self-service portal. Service Catalog is built on top of CloudFormation and adds exactly those governance features. Use CloudFormation to author the template; use Service Catalog when you need governed self-service on top of it.
How does Service Catalog relate to AWS Control Tower?
Control Tower’s Account Factory uses Service Catalog under the hood to provision new accounts as products. Control Tower governs at the account and landing-zone level; Service Catalog governs resource provisioning within accounts. “Self-service account creation” → Control Tower; “self-service resource provisioning” → Service Catalog.
How do I share a Service Catalog portfolio across many accounts?
You can share a portfolio directly with specific account IDs (the receiving account imports it) or, with AWS Organizations integration, share it with the entire Organization or specific OUs so member accounts receive it automatically. Ensure any launch-constraint provisioning roles exist in the consuming accounts so shared products can deploy.
Conclusion
AWS Service Catalog is the answer to a very specific and very common organizational problem: giving teams the freedom to provision infrastructure themselves while the platform team keeps control of what gets built, how, and by whom. Products carry the approved configuration; portfolios carry the access and governance; constraints — especially the launch constraint — enforce least-privilege self-service; TagOptions enforce consistent tagging; and Organizations sharing distributes it all across the account fleet. For the SAP-C02, the skill is mapping each governance requirement to the right mechanism and cleanly distinguishing Service Catalog from CloudFormation, StackSets, and Control Tower. Get that mapping fluent and the exam’s organizational-complexity scenarios stop being tricky and start being predictable.