While reviewing a design for a municipal notifications service, an architect cites twelve-factor as guidance for portable, disposable processes with externalized configuration. How should that guidance be treated on the exam?
Select an answer to reveal the explanation.
Short Explanation
Twelve-factor is a toolkit of habits—like a municipal building code for portable services—not a quiz to recite factor numbers in order. Apply the practices to design choices. It is not an OCI product or a VCN standard.
Full Explanation
Twelve-factor guidance for the municipal notifications service should be treated as a family of practices for cloud-native process design that you apply to concrete choices—portable processes, externalized configuration, disposability, and related habits—not as sacred liturgy. On the exam, you map those practices to design decisions such as one artifact per environment with env-supplied config, rather than memorizing an ordered flash-card list of twelve names.
Treating twelve-factor as a mandatory ordered recital of twelve names misses the point: the exam tests application of the practices, not rote enumeration. Treating it as an Oracle-branded OCI product that replaces Functions and API Gateway invents a SKU that does not exist; twelve-factor is methodology, not a console service. Treating it as a networking standard that defines VCN CIDR ranges confuses application process design with tenancy network addressing.
Exam caveat: know the spirit of the practices (config in the environment, disposable processes, backing services as attached resources) and apply them; do not expect a product picker labeled “Twelve-Factor Service.”
Operational check: review the notifications design for one build artifact across environments, config and secrets supplied at runtime, and processes that can be stopped and replaced without local snowflake setup—then adjust any gap against those practices.