What makes software development testing environments challenging to secure?

• A. They are temporary and may not be configured with an organization's standard level of security
• B. They always mirror production security controls
• C. They are on isolated networks
• D. They do not run actual code

Answer: (A)

The main idea here is that testing environments are temporary and often bypass the normal security hardening that permanent systems receive. Because these environments are spun up quickly for short periods, teams may skip applying the organization’s standard security baselines, use default credentials, skip patching, or load non-production data. They may also be created outside the usual change-control processes and then discarded without proper decommissioning, leaving residual access or exposed data. All of this makes it easy for misconfigurations to slip in and for sensitive information to be exposed, which is the core security challenge for development and testing setups.

The other statements don’t capture this real-world risk as clearly. Mirrors of production security controls are not guaranteed in practice—testing environments are often less hardened. Isolation can help security but isn’t something you can assume across all setups. And testing environments typically do run actual code, so the challenge isn’t about running no code at all.