You need to set up a local package repository to serve 75 client systems. Multiple clients will being the package repository concurrently and you need to ensure that the local repository performs…

Question

Options

• ASet up multipathing on the package repository server to distribute the network load multiple network
• BDeploy a second instance of the package repository server to run as a read writable mirror.
• CDeploy a second instance of the package repository server to run as a read-only mirror.
• DDeploy a second instance of the package repository server to run as a clone of the primary repository server.
• EDeploy a package repository locally on each client.

• A
  6% (1)
• B
  6% (1)
• C
  75% (12)
• E
  13% (2)

Explanation

A read-only mirror is correct because client systems only ever read from a package repository - they download and install packages, never write to it. Deploying a second read-only mirror splits the read load across two servers, directly improving throughput for the exact bottleneck: many clients simultaneously pulling packages.

Why the others fail:

• A (Multipathing): Multipathing provides redundant network paths to the same server for failover - it doesn't add a second server or distribute client load.
• B (Read-writable mirror): A writable mirror introduces complex two-way sync and conflict management with no benefit, since clients never need to write to the repo.
• D (Clone): A "clone" implies a static one-time copy, not a live, synchronized mirror - it would quickly become stale and doesn't imply load sharing.
• E (Local repo per client): Maintaining 75 separate repositories is a storage and administrative nightmare and defeats the purpose of a centralized repo.

Memory tip: Match the capability to the workload - package installs are read-only operations, so scale with a read-only mirror. If clients only read, your mirror only needs to read.

No community discussion yet for this question.