A Microsoft Fabric Data Factory pipeline uses one Copy activity to load a very large partitioned table from a source database into a Lakehouse. The source supports parallel reads on its partition key and the destination storage is far from saturated, yet throughput stays low because the copy reads the source on a single stream. The team wants to raise sustained throughput by reading the source in parallel while keeping a single Copy activity. Which TWO configuration changes on the Copy activity together best raise throughput? Select TWO.
- AEnable source partitioning on the partition key so the Copy activity issues multiple concurrent read partitions against the source instead of one serial stream. Correct
- BRaise the degree of copy parallelism so more partitions are read and written at the same time, using the available source and destination headroom. Correct
- CSet the Copy activity to a single intra-activity retry with a longer interval so transient stalls do not restart the whole serial read from the beginning.
- DLower the destination batch size so each write commits sooner, which the team expects to free the source stream to read the next block faster.
Why A is correct: Source partitioning splits the read into independent partition queries the activity can run concurrently, which is what removes the single-stream bottleneck described.
Why B is correct: The degree of copy parallelism controls how many partitioned reads and writes run concurrently, so increasing it consumes the spare source and sink capacity to lift throughput.
Why C is wrong: Retries help recover from transient faults but do nothing to parallelise the read, so the activity still copies on one stream and throughput stays low.
Why D is wrong: A smaller batch size adds commit overhead and does not parallelise the single source read, so it fails to address the stated serial-read bottleneck.