1D0-520 · Question #122
During a project meeting, Eric explains the need for a development server to host the company's new Web site during development. Eric's IT co-workers want to know who will have access to the…
The correct answer is B. The development server will be accessible to the development team and to authorized. See the full explanation below for the reasoning.
Question
During a project meeting, Eric explains the need for a development server to host the company's new Web site during development. Eric's IT co-workers want to know who will have access to the development server. What should Eric tell them?
Options
- AThe development server will be accessible to all members of the organization as well as the
- BThe development server will be accessible to the development team and to authorized
- CThe development server will be accessible to the public in order to collect public opinion on
- DThe development server will be accessible to all members of the organization in order to
How the community answered
(25 responses)- A4% (1)
- B80% (20)
- C4% (1)
- D12% (3)
Community Discussion
5The correct answer is B. A development server exists solely for the dev team and any stakeholders who are explicitly authorized, keeping it off the public internet and away from the broader org to prevent exposure of unfinished, potentially vulnerable code before it ever reaches production.
I actually leaned toward D at first because it felt natural that the whole org would want visibility into a new company site during development, but then I thought about what a dev server actually is in practice. If you spin up even a simple staging environment, you keep it locked to the dev team and whoever they explicitly authorize, because opening it wider invites feedback loops, security exposure, and broken builds being seen by people who do not need to see them.
The least-privilege principle covers this exactly, and most vendor security frameworks (NIST SP 800-53 AC-6, for one) treat restricting dev environment access to authorized personnel as a documented control, not just a convention people picked up from habit.
D makes sense if you think about what a dev server actually does inside a company. The whole organization has a stake in how the site turns out, so giving all internal members access to review progress and provide feedback before launch is exactly the kind of collaborative internal process that keeps a project from going sideways. B sounds tempting but locking it down to just the dev team defeats the purpose of getting organizational buy-in during development.
Viktor, the vendor docs are clear that a development server is meant for the development team only, which is why B is correct. Exposing it to the broader organization introduces unnecessary security risk and is outside the controlled scope that exam objectives define for that environment.