Practice vocabulary for enterprise architecture governance including ARB, RFCs, architecture debt, and alignment with enterprise architecture standards.
0 / 18 completed
1 / 18
The body responsible for reviewing and approving significant architectural decisions in large enterprises is called the _____.
The Architecture Review Board (ARB) is a governance body that evaluates proposed architectural changes against enterprise standards before implementation is approved.
2 / 18
'The RFC must be approved by the ARB before implementation' means that _____.
An RFC (Request for Comments) in enterprise contexts is a formal proposal document. ARB approval ensures architectural changes align with standards before work begins.
3 / 18
When teams have accumulated architectural decisions that are inconsistent with enterprise standards, this is called _____.
Architecture debt refers to accumulated deviations from agreed architectural standards — decisions that worked short-term but create misalignment, complexity, or risk over time.
4 / 18
The primary purpose of an architecture governance process is to _____.
Architecture governance ensures that individual project decisions remain consistent with the enterprise-wide architecture strategy, avoiding fragmentation and technical debt.
5 / 18
An architecture governance review that finds a proposed system uses a non-standard database technology would likely _____.
When a proposal deviates from approved standards, governance processes typically require either a formal exception (with documented rationale) or a redesign to use the standard technology.
6 / 18
PR Description:
"Just finished implementing the new user authentication flow. Using MongoDB for session storage – seems like a good fit! No need to discuss this with anyone."
This scenario highlights a common issue. While developers often have great technical instincts, ignoring architecture governance processes can lead to significant problems down the line. The developer's response demonstrates a lack of awareness regarding established review procedures and potential risks associated with choosing non-standard technologies like MongoDB for session storage. PR Descriptions should always include justification and acknowledge alignment with architectural guidelines.
7 / 18
During a code review, Sarah notices this PR and comments in Slack: 'Hey Mark, while that's efficient, we have an architecture governance policy requiring all session stores to use PostgreSQL. Could you briefly explain your reasoning for choosing MongoDB here?' Which of the following best describes Sarah's action?
Mark replied: 'MongoDB is faster and easier to scale.'
Sarah's comment represents a formal challenge to the existing governance process. She isn't simply suggesting an improvement; she's highlighting a discrepancy between Mark's choice and the pre-defined policy. The key here is that architectural governance isn't about 'good ideas'; it's about ensuring consistency and adherence to established standards, even if a different solution appears technically superior. Option A incorrectly frames this as a technical suggestion, while options B and C misinterpret the role of governance – it's not about escalation or immediate implementation without review.
8 / 18
PR Description:
"Just finished implementing the new user authentication flow. Using MongoDB for session storage – seems like a good fit! No need to discuss this with anyone."
This scenario highlights a common issue. While developers often have great technical instincts, ignoring architecture governance processes can lead to significant problems down the line. The developer's response demonstrates a lack of awareness regarding established review procedures and potential risks associated with choosing non-standard technologies like MongoDB for session storage. PR Descriptions should always include justification and acknowledge alignment with architectural guidelines.
9 / 18
During a code review, Sarah notices this PR and comments in Slack: 'Hey Mark, while that's efficient, we have an architecture governance policy requiring all session stores to use PostgreSQL. Could you briefly explain your reasoning for choosing MongoDB here?' Which of the following best describes Sarah's action?
Mark replied: 'MongoDB is faster and easier to scale.'
Sarah's comment represents a formal challenge to the existing governance process. She isn't simply suggesting an improvement; she's highlighting a discrepancy between Mark's choice and the pre-defined policy. The key here is that architectural governance isn't about 'good ideas'; it's about ensuring consistency and adherence to established standards, even if a different solution appears technically superior. Option A incorrectly frames this as a technical suggestion, while options B and C misinterpret the role of governance – it's not about escalation or immediate implementation without review.
10 / 18
PR Description:
"Just finished implementing the new user authentication flow. Using MongoDB for session storage – seems like a good fit! No need to discuss this with anyone."
This scenario highlights a common issue. While developers often have great technical instincts, ignoring architecture governance processes can lead to significant problems down the line. The developer's response demonstrates a lack of awareness regarding established review procedures and potential risks associated with choosing non-standard technologies like MongoDB for session storage. PR Descriptions should always include justification and acknowledge alignment with architectural guidelines.
11 / 18
During a code review, Sarah notices this PR and comments in Slack: 'Hey Mark, while that's efficient, we have an architecture governance policy requiring all session stores to use PostgreSQL. Could you briefly explain your reasoning for choosing MongoDB here?' Which of the following best describes Sarah's action?
Mark replied: 'MongoDB is faster and easier to scale.'
Sarah's comment represents a formal challenge to the existing governance process. She isn't simply suggesting an improvement; she's highlighting a discrepancy between Mark's choice and the pre-defined policy. The key here is that architectural governance isn't about 'good ideas'; it's about ensuring consistency and adherence to established standards, even if a different solution appears technically superior. Option A incorrectly frames this as a technical suggestion, while options B and C misinterpret the role of governance – it's not about escalation or immediate implementation without review.
12 / 18
PR Description:
"Just finished implementing the new user authentication flow. Using MongoDB for session storage – seems like a good fit! No need to discuss this with anyone."
This scenario highlights a common issue. While developers often have great technical instincts, ignoring architecture governance processes can lead to significant problems down the line. The developer's response demonstrates a lack of awareness regarding established review procedures and potential risks associated with choosing non-standard technologies like MongoDB for session storage. PR Descriptions should always include justification and acknowledge alignment with architectural guidelines.
13 / 18
During a code review, Sarah notices this PR and comments in Slack: 'Hey Mark, while that's efficient, we have an architecture governance policy requiring all session stores to use PostgreSQL. Could you briefly explain your reasoning for choosing MongoDB here?' Which of the following best describes Sarah's action?
Mark replied: 'MongoDB is faster and easier to scale.'
Sarah's comment represents a formal challenge to the existing governance process. She isn't simply suggesting an improvement; she's highlighting a discrepancy between Mark's choice and the pre-defined policy. The key here is that architectural governance isn't about 'good ideas'; it's about ensuring consistency and adherence to established standards, even if a different solution appears technically superior. Option A incorrectly frames this as a technical suggestion, while options B and C misinterpret the role of governance – it's not about escalation or immediate implementation without review.
14 / 18
David from the Infrastructure team sends this Slack message after a new microservice was deployed:
'Just spun up the new-payment-processor. It's using Redis for caching – figured it would be faster than our existing database. No need to flag this, right?'
This question tests understanding of proactive governance. The core issue isn't the use of Redis itself, but that it wasn't discussed or approved according to established processes. The ArchGov_v2.1 document likely dictates standards for new services, and failing to follow this demonstrates a lack of awareness. Choosing 'incorrect' acknowledges that bypassing governance procedures can lead to issues later.
15 / 18
During a standup meeting, Emily (Frontend Lead) says: 'I've built a new API endpoint for user profile updates. I chose GraphQL because it's more flexible and efficient than REST. It doesn't need any review.' What does this statement primarily highlight concerning architecture governance?
While Emily's reasoning about GraphQL might be valid, the statement misses the crucial element of governance: documented and approved architectural choices. Architecture governance isn't just about 'what' is used but *why* and how it aligns with broader strategy. Simply stating a benefit doesn't satisfy governance requirements; justification and approval are essential for maintaining consistency.
16 / 18
Ben, a Senior Developer, submits a PR with the following description:
'Implemented the new user onboarding flow. Using DynamoDB for storing user data – fast and scalable!'. A governance review identifies this as a potential violation of the enterprise architecture. What's the MOST appropriate response from the Governance team?
This scenario focuses on collaborative governance. The review isn't about simply saying 'no'; it's about educating Ben and explaining why DynamoDB might not be suitable for the enterprise architecture. A good governance process emphasizes discussion, understanding, and risk mitigation, rather than a punitive response. Escalating to the VP is overkill.
17 / 18
The term 'technical debt' in the context of architecture governance refers to:
'Technical debt' in this context is a common metaphor. It represents the consequences of not following established architectural guidelines – essentially, short-term decisions that create long-term problems. This highlights the importance of preventative governance to avoid accruing excessive technical debt.
18 / 18
Chloe is reviewing a PR for a new data pipeline. The proposed solution uses a message queue system (Kafka) to handle real-time data ingestion. During the review, she notes that this isn't documented in the current architecture standards. What's the *best* action Chloe should take?
This question tests a nuanced understanding of iterative governance. It's not about immediately rejecting the PR; it's about engaging in a dialogue with the developer to understand their choices and determine if they align with architectural principles. Updating standards proactively is an option, but discussion first is key.
What does the "Architecture Governance Vocabulary" exercise cover?
Practice vocabulary for enterprise architecture governance including ARB, RFCs, architecture debt, and alignment with enterprise architecture standards.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
How many questions are in "Architecture Governance Vocabulary"?
This exercise has 18 questions. Each one gives instant feedback with an explanation, so you can see exactly why an answer is right or wrong.
Do I need to create an account to save my progress?
No account is required. The progress bar and score are tracked in your browser for the current session -- the exercise is designed to be a quick, repeatable drill rather than something you resume later.
What happens if I get an answer wrong?
You'll see the correct answer highlighted immediately, along with a short explanation of why it's correct. Wrong answers aren't penalized beyond your score, and you can keep going through every question.
How is this exercise different from reading an article?
Articles explain vocabulary and concepts through prose, while exercises like this one are interactive drills -- multiple-choice questions -- that test and reinforce your recall of specific terms and phrasing.
Can I retry this exercise?
Yes -- use the "Try again" button on the results screen to reset your score and go through all the questions again from the start.
Where can I find more Enterprise Architecture Language exercises?
Browse the full Enterprise Architecture Language hub for related drills, or check the site-wide exercises index for other IT English topics.
Is this exercise suitable for beginners?
This exercise assumes basic familiarity with IT terminology. If a term feels unfamiliar, check the site Glossary for a plain-English definition before attempting the questions.
How often is new content like this published?
New exercises are added regularly across all categories, alongside new vocabulary sets and articles. Check back on the exercises hub to see what's new.