Centralize a domain and shared-library repository in the shared services account and use it as upstream for team repositories
A company has an organization in AWS Organizations for its multi-account environment. A DevOps engineer is developing an AWS CodeArtifact based strategy for application package management across the organization. Each application team at the company has its own account in the organization. Each application team also has limited access to a centralized shared services account. Each application team needs full access to download, publish, and grant access to its own packages. Some common library packages that the application teams use must also be shared with the entire organization. Which combination of steps will meet these requirements with the LEAST administrative overhead? (Choose three.)
Community Votes
100% of anonymous learners picked answer BCD. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
Team autonomy is provided by per-team repositories in the team's own account with full read and write (C), which the account model already isolates, so no cross-account resource policy juggling is needed (A and E are unnecessary). Org-wide sharing of common libraries is best served by a single repository in the shared services account with organization read access, wired in as the upstream repository for every team repository (D), which makes dependency resolution automatic instead of requiring each team to be granted access per repository. The domain in the shared account (B) is what makes cross-repository upstream relationships and organization-wide access possible with one grant.
Each application team needs full control over its own packages in its own account, while common libraries must be shared org-wide, and the design must minimize administrative overhead. Creating a domain in the shared services account and granting the organization read and CreateRepository access makes it available to every team (B). Each team creates its own repository in its own account with full read and write access to its own packages (C). A separate repository in the shared services account holding the common libraries is granted organization-wide read access and set as the upstream repository for each team's repository, so common packages resolve automatically (D).
Creating a domain in each application team's account and granting cross-account access to it (A) — this inverts the intended topology; each team already has its own account, so a per-team domain adds no value and complicates organization-wide sharing. Creating resource-based policies on individual repositories to let other teams read shared packages (E) — this requires a policy per repository and per team and grows combinatorially; TEC1 favored this with D, but limelight04 correctly noted it adds complexity versus the upstream repository model, and the question asks for the least administrative overhead.
Community Discussion (5 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
A domain in the shared services account, with the organization granted read access and CreateRepository, provides the central construct that lets every team create and consume repositories without individual cross-account grants (B). Each application team then creates its own repository inside its own account and grants its own account full read and write access, which satisfies the requirement that the team fully download, publish, and grant access to its own packages (C). For the common libraries, a single repository in the shared services account is granted organization-wide read access and configured as the upstream repository for each team's repository (D); because upstream relationships are transitive at the package-manager level, common packages are then resolved automatically without any per-team or per-package grant, which is what minimizes administrative overhead.Why the Other Options Are Wrong
A creates a domain in each application team's own account and grants that team's account read and write to its own domain. Since every team already has a dedicated account, per-team domains add organizational units without benefit and make organization-wide sharing harder, since there is no single domain to attach the shared repository to. E creates resource-based policies granting read access on individual repositories to other teams' accounts; this requires a policy for each shared repository and grants to each consuming account, which scales poorly and contradicts the least-administrative-overhead requirement. Note that TEC1 advocated the B, D, E combination, but limelight04's point is decisive: the upstream repository relationship achieves the same sharing with a single configuration instead of pairwise grants. B, C, and D are the correct combination.Community Comment Notes
Community voted B,C,D (80), with B,C,E and B,D,E alternatives appearing in the minority. Commenters explained that B centralizes the domain, C gives each team full control of its own packages, and D plus the upstream repository makes shared libraries resolve automatically. limelight04 argued against E precisely because it requires each team to set up access to the shared account's repository rather than relying on the upstream model.Official Reference
Related Analysis
Practice All DOP-C02 Questions
Access 85 questions with complete answers and detailed explanations.
View Full DOP-C02 Practice Test →