This set builds vocabulary for API-first content management decoupled from presentation.
0 / 5 completed
1 / 5
At standup, a dev mentions a content management system that stores and serves structured content via an API, with no built-in frontend templating or rendering. What is this architecture called?
A headless CMS like Contentful stores and serves structured content through an API, deliberately decoupled from any specific frontend templating or rendering layer, so the same content can be consumed by a website, mobile app, or any other client independently. This separation contrasts with a traditional CMS where content storage and page rendering are tightly bundled together. It gives development teams flexibility to build the frontend with whatever framework or platform best suits each channel.
2 / 5
During a design review, the team defines a reusable content model, like an "Article" type with a title, body, and featured image field, before any content is created. What does this represent?
Content modeling defines a reusable schema, like an "Article" type with specific fields for title, body, and image, before any actual content entries are created, establishing a consistent structure that every entry of that type must follow. This upfront schema design is foundational to a headless CMS, since the API relies on that structure to serve predictable, consistently shaped data to any consuming frontend. Getting this model right early avoids costly restructuring once significant content has already been created.
3 / 5
In a code review, a dev configures a webhook that automatically triggers a static site rebuild whenever a content editor publishes a change. What does this integration represent?
A webhook-triggered build automatically kicks off a site rebuild the moment a content editor publishes new or updated content, keeping a statically generated frontend in sync with the CMS without requiring a developer to manually trigger every deployment. This automation is especially important for a headless CMS paired with a static site generator, where the site itself doesn't dynamically fetch content on every page load. It reflects a broader Jamstack pattern of decoupling content publishing from the deployment pipeline.
4 / 5
An incident report shows a frontend broke in production because a content editor removed a required field the frontend code depended on without any validation. What practice would prevent this?
Enforcing required-field validation at the content model level, and reviewing any proposed schema change for its impact on the frontend code that consumes it, prevents an editor's seemingly harmless content change from silently breaking a production site that assumed a certain field would always be present. Treating content model changes with the same care as an API contract change is essential in a headless architecture. This coordination between content and engineering teams is a common practical challenge of the decoupled headless model.
5 / 5
During a PR review, a teammate asks why the team chose a headless CMS instead of a traditional CMS with built-in page templates. What is the reasoning?
A traditional CMS tightly couples content to its rendering templates, making it harder to reuse the same content across a website, mobile app, and other channels without duplicating effort. A headless CMS's API-first architecture decouples that content from any specific presentation layer, letting each channel's frontend be built independently using whatever technology fits best. The tradeoff is that a headless CMS requires the team to build and maintain its own frontend rendering layer rather than getting one built in.