Answer Key DG3-049–DG3-064
DG3-049 — A
Why: Figure 20 puts most conflict resolution at tactical/operational levels; escalate only unresolved/strategic issues. B overloads top authority; C confuses data semantics with IT Governance; D is unnecessary redesign.
Source: pp. 88–89; Figure 20.
DG3-050 — B
Why: illustrative pattern ≈80–85% low, <20% DGC, <5% Steering. These are not quotas but express the narrowing funnel.
Source: p. 89; Figure 20.
DG3-051 — C
Why: governance standards should be mandatory, measurable/auditable, communicated, monitored, reviewed and enforceable. Standards are not optional; procedures are not the only enforceable artifact; policy and standards have different roles.
Source: pp. 91–92.
DG3-052 — D
Why: Business Glossary is an agreed business-term resource linked to data and richer Metadata. A is too narrow; B is technical-only; C wrongly substitutes glossary for Architecture.
Source: pp. 92–93.
DG3-053 — A
Why: source says architects + stewards develop/maintain enterprise model together and DGC can review/approve/formally adopt. Steering does not replace stewardship; model is not IT-only; glossary/model are complementary.
Source: p. 93.
DG3-054 — B
Why: several valuation approaches are acceptable and DGC can organize/standardize organizational method. No universal DAMA formula; value isn't limited to external sale; risk costs explicitly matter.
Source: pp. 79–81, 93.
DG3-055 — C
Why: DG is organizational behavior/authority; clarify goals, roles, workflows and requirements before tool selection. A/D assign authority to software; B invents a tool prerequisite.
Source: p. 94.
DG3-056 — D
Why: Chapter 3 supports incremental rollout adapted to maturity, engagement, funding and priority. A is unsupported big-bang; B waits for impossible uniform maturity; C reverses behavior-before-tools logic.
Source: p. 90; pp. 95–96.
DG3-057 — A
Why: ongoing funding/process/measurement/adoption proves embedding. Kickoff or website proves only launch/support; roadmap completion does not end governance.
Source: p. 73; pp. 93–94.
DG3-058 — B
Why: data-centricity means data as corporate asset aligned to business strategy, quality and continuous DM improvement—not merely newer technology, IT-only decisions or physical centralization.
Source: p. 75.
DG3-059 — C
Why: Figure 16 is a generic model of governance bodies/responsibilities to adapt—not mandatory org chart, maturity ladder or IT-only hierarchy.
Source: pp. 75–76; Figure 16.
DG3-060 — D
Why: 2.1–2.17 are a structured body of governance work, but the chapter also stresses tailoring, iteration and incremental rollout. A is false rigidity; B ignores their implementation relationship; C makes organizational work a tool checklist.
Source: pp. 81–96.
DG3-061 — A
Why: named regulations are source examples illustrating compliance governance. The governance lesson is applicability, controls, evidence, monitoring, penalties/remediation—not memorizing a supposedly complete current list. Legal specialists are not replaced.
Source: pp. 89–90.
DG3-062 — B
Why: OCM includes feedback, incentives/KPIs and reinforcement; repeating messages or buying tools does not fix behavior incentives, and removing stakeholders contradicts shared/collaborative governance.
Source: pp. 87–88.
DG3-063 — C
Why: significant data requirements should be captured early in planning/design with governance/PMO coordination. A is too late; B confuses with IT Governance; D ignores architecture/regulation/SOR requirements.
Source: pp. 86–87.
DG3-064 — D
Why: Chapter 3 groups drivers around reducing risk and improving processes, explicitly tying governance to business strategy/measurable problems. Committees, IT modernization or governance-for-its-own-sake are not the goal.
Source: pp. 72–73.