Benefits of running managed code under the CLR: which combination is true for code safety and resource management?

Introduction / Context:
Managed execution under the CLR provides stronger guarantees than raw native execution. Type safety, memory isolation, and automatic garbage collection make applications more robust and secure by default.

Given Data / Assumptions:
The listed benefits are:

• 1) Type safety of the code is assured.
• 2) Prevents applications from accessing memory they are not authorized to access.
• 3) Launches a separate process for every application.
• 4) Resources are garbage collected.

Concept / Approach:
Items 1 and 2 reflect verification and managed isolation guarantees, reducing buffer overrun and illegal memory access risks. Item 4 reflects automatic memory management via the GC. Item 3 is incorrect because process creation is an operating system concern; the CLR can host multiple managed applications and application domains without implying a one-process-per-app mandate.

Step-by-Step Solution:
Confirm 1 → true: verification and JIT constraints enforce type-safety rules.Confirm 2 → true: managed code cannot directly index arbitrary memory.Confirm 3 → false: CLR does not enforce one-process-per-app.Confirm 4 → true: GC reclaims unreachable objects.

Verification / Alternative check:
Review CLR execution model: application domains, verification, and GC are well-documented features; process boundaries are not dictated by CLR.

Why Other Options Are Wrong:
Any set including item 3 incorrectly attributes OS-level behavior to the CLR.

Common Pitfalls:
Confusing application domains with processes; AppDomains are logical isolation units inside a process (in classic .NET Framework).

Final Answer:
Only 1, 2 and 4