SitecoreAI CMS Developer Exam Prep: My Study Notes

I've been preparing for the SitecoreAI CMS Developer certification, and these are my study notes. They are not a tutorial. They are the facts I need to have straight: which API takes which key, what a serialization scope does, where a webhook stops being useful, what the Deploy app can and can't do.

The questions are multiple choice, and most of the wrong options are close to right. Knowing the exact detail is what separates them, so the notes are grouped by topic and written around those details. They are just as useful on a real project.

Rendering strategy in the Content SDK

The question is always the same: how fresh does this page need to be, and does Google need to see it?

• Fresh on every request and indexable: SSR in the Pages Router, or a Server Component in the App Router.
• Changes occasionally, a little stale is fine: ISR. It is still stale between revalidations, so it doesn't fit volatile data.
• Rarely changes: SSG.
• Client-side fetching (useEffect, lazy-load) is not in the initial HTML, so search engines can't rely on it.

In the App Router, components are Server Components by default. Mark one as a client component only if it uses state, effects or browser APIs. The App Router template generates two component maps, one for server and one for client components, to keep their code apart.

For local development against SitecoreAI it is just npm run dev.

Standard values

Standard values live in a child item of the template called __Standard Values. A field shows its standard value when the item's own value is empty (NULL).

• They can hold: default field values, insert options, initial workflow, and presentation (layout and renderings).
• They can't: lock fields (use security for that), or generate sitemaps.

My rule: set layout, initial workflow and insert options in the template's standard values, not on individual items. Otherwise you end up fixing the same thing item by item.

One small trap. The $name token is replaced with the item name when the item is created. It is not updated if the item is renamed later.

Experience Edge publishing and APIs

Publishing to Edge builds a snapshot in three steps: calculating additional entities, calculating dependencies, resolving dependencies. Archiving expired content is not one of them.

Templates appear in the Edge schema only if they sit under /sitecore/templates/Foundation, Feature, Project or User Defined. Create new templates in those locations. Standard template fields are not available in Edge unless you add them with a patch file.

The two GraphQL APIs are easy to mix up:

• Preview GraphQL API: draft and published content from the Content Management instance. Use it for local development and non-production environments.
• Delivery GraphQL API: published content only, served from Experience Edge. Use it for production.

Use the Preview Context ID for Preview and the Live Context ID for Delivery. Visual editing in Pages always uses the Preview Context ID. Both GraphQL APIs are read-only.

To use the Delivery IDE, generate a Delivery API token in the Deploy app and put it in the HTTP HEADERS tab as the sc_apikey header. That is also the header you send to the Delivery API from code.

The Admin API (bearer JWT) is where you clear the tenant cache and create webhooks. Webhooks must use HTTPS. The default OnEnd execution mode runs the webhook at the end of a publishing job, which is how you trigger a front-end cache clear after publish.

Components and variants

• Same content in different layouts: one component with several Headless variants.
• A variant is a named, configurable presentation of the same component. In code it is usually a named export. Variants are defined under the site's Presentation > Headless Variants.
• Rendering parameters control behavior and presentation options for the component across all of its variants.
• Editors set CSS styles in Pages: add the IStyling base template to the rendering parameters template. The options they see are configured under the site's Presentation > Styles.

FED First deserves its own sentence. The local front-end connects to the SitecoreAI preview endpoint, so front-end and back-end work run in parallel. It is not mock-data-only work.

Workflows and webhooks

SitecoreAI has three webhook types: webhook event handler, webhook submit action and webhook validation action. Which one you pick depends on when you need to know:

• Submit action: fires when a workflow reaches a state. For example, a call when an item reaches the approved state.
• Validation action: runs before the move and can block it. The endpoint must answer with IsValid true or false. If it does not validate, the item does not change state.
• Event handler: watches item and publish events, and is not tied to workflow states.

You need a developer or admin role to create webhooks. If the endpoint needs authentication, create an authorization item.

Two limits to plan around. A failed request is not resent, and the default maximum time for all webhooks in a request is 10 seconds. Webhooks notify external services. They are not for business logic inside SitecoreAI.

Serialization (SCS)

• sitecore.json: global settings, including excluded fields and the list of modules.
• *.module.json: includes, rules, and fields excluded for that module only.
• xmcloud.build.json: defines the editing hosts, build targets, the serialization modules to deploy, and post actions.

To limit serialization to an item and its direct children, set scope on the include. The values are SingleItem (only the item), ItemAndChildren (the item and its immediate children), ItemAndDescendants (the default) and DescendantsOnly. Ignored works only in rules, not in includes.

Owner, Revision, Updated, UpdatedBy and Lock are always excluded from serialization.

Environments and deployment

Project creation runs three processes: provision, build, deploy. After deploy, post actions run in order: CM warm-up, deploying SCS modules, schema population, reindexing, publishing.

• Automate environment creation: the Sitecore CLI cloud commands (for example, dotnet sitecore cloud environment create) or the Deploy REST API.
• Move the project to a new repo: in the Deploy app, open the project, choose Options > Edit project and pick the new repository. Then choose the branch for each environment. The new code is not deployed automatically, so create a build and deploy it. SCS is the wrong tool for this.
• Build fails: read the deployment log in the Deploy app first. It covers provisioning, the build, deployment and post actions.
• The Deploy app supports GitHub and Azure DevOps. For other providers, use the Sitecore CLI.
• An environment linked to a branch can auto-deploy on every push to that branch.
• The maximum repository size for deployment is 500 MB.
• The Deploy app is available to Organization Admins and Organization Owners only.

Authoring and Management GraphQL API

• Limits: no subscriptions, no creating or deleting users through the Security API, no GET requests.
• Supported: index rebuilds, job status, publishing operations.

Cloud Portal roles

• Organization Owner and Organization Admin: the highest role in all apps. They can invite users and manage organization settings. Only an Owner can add or remove an Owner.
• Organization User: can open only the apps they are given an app role for. Use this role to give a team member access to specific applications.

If a role is missing for an action in the Deploy app, an Organization Admin or Owner changes it in the Cloud Portal.

Sites and site collections

• A site collection groups related sites that share templates and media. Sites inside one collection can share content, components and layout elements.
• For a company with several brands and countries: one site collection per brand, and one site per country.
• A headless site contains Home (pages), Media and Data (reusable datasources). Presentation holds Page Designs, Partial Designs and Placeholder Settings.
• Site names cannot contain spaces.
• Content SDK supports multi-site apps, so one rendering host app can serve several sites.

Placeholder restrictions

Set them in Placeholder Settings: add the placeholder key (for example headless-footer) and choose the renderings in Allowed Controls. Restrictions set this way apply to every page in the site.

Spotting wrong answers

Some of the wrong options give themselves away. These are the patterns I look for in practice questions:

• An option that describes a setting you've never seen in Sitecore is probably invented.
• An option that uses a tool for the wrong job is probably a trap (SCS to move a repo, for example).
• Options with "always", "only" or "automatically" deserve a second look.

Sources

• Publishing to Experience Edge
• The Experience Edge schema
• Authorization and API access
• Set up the GraphQL IDEs
• Experience Edge Admin API
• Webhook execution modes
• Webhooks in SitecoreAI
• Authoring and Management API limitations
• Standard values for data template fields
• Sitecore Content Serialization configuration reference
• Excluded fields
• Manage a project (Deploy app)
• The deployment log
• The SitecoreAI build configuration
• Create a SitecoreAI project using the Sitecore CLI
• Deploy API
• Cloud Portal roles
• Create a headless site collection and site
• Set placeholder restrictions
• Manage component maps for client and server components
• Connect your Content SDK app to SitecoreAI
• Getting started with SitecoreAI (FED-first)