ApexIntermediatecustom-metadataconfigurationdevops
Implement custom metadata driven Apex configuration
Real World Scenario
Hardcoded endpoint URLs and feature toggles in Apex require deployments for every environment change.
Expected Answer
• Store config in Custom Metadata Types deployable via metadata API
• Hierarchy Custom Settings for user/profile overrides where appropriate
• Apex reads CMDT via getAll or SOQL on __mdt with caching
• Environment-specific values deployed per org via CI/CD pipeline
• Validate required config at startup scheduled job alerting missing records
• Avoid secrets in CMDT—use Named Credentials and Protected Custom Settings
• Document CMDT schema changes impact on running async jobs
Follow-Up Questions & Answers
Click to expand — each follow-up includes a direct, interview-ready answer
Main difference: use case and scale. Store config in Custom Metadata Types deployable via metadata API. Hierarchy Custom Settings for user/profile overrides where appropriate. Pick based on your integration pattern and team capability. Configuration belongs in metadata, not code constants—architects block magic strings in review. Balance speed of delivery with maintainability.
Architect Perspective
Configuration belongs in metadata, not code constants—architects block magic strings in review.