Templates, Policies, and Editable Template Design
Editable templates separate structure from content and are the default for new Sites projects. A candidate must understand the three artifacts: the template definition (under /conf, referencing a template type), the template type (page component plus allowed components), and the policies (design properties stored per template). Know the roles: template authors create templates, content authors build pages, developers define component structure. Understand the initial content, the responsive grid, the layout container, and how policy mappings control which components appear in the component browser.
Key concepts include the difference between static templates (structure under /apps, edited by developers) and editable templates (structure stored as content, edited by template authors), the locked versus unlocked structure components, and how policies replace classic design mode. Know that policies can be set at template level and overridden at page level, and that the Style System lets authors pick predefined style variations defined in component policies.
Traps are frequent here. A question may claim editable templates allow changing component markup in the UI, which is false: markup stays in code. Another trap confuses policy inheritance with dialog inheritance. Expect questions on why a component does not appear in the browser (missing policy or template type allowlist) and on the difference between the template's structure and its initial content. Also watch for questions implying static templates are deprecated and unusable; they still exist but are not recommended for new work.
Rule of thumb: if authors need to change layout, locked components, or allowed components per page, use editable templates and policies. Worked example: a marketing team wants per-page control over which components are available. Define a template type with a broad allowlist, then narrow it with page-level policies.