Explanation:

Correct Answer:
D. Update the change set and re-deploy ✅

Why this is correct:
Once a change set is deployed, you can go back to the source org (Developer Sandbox), open the same outbound change set, and add/remove/update components.
After saving, you can upload it again to the target org (Developer Pro Sandbox) and then re-deploy.
This is the proper way to move updated components after initial deployment.

Why not the others:

A. Refresh the test sandbox and re-deploy the change set ❌
Refreshing a sandbox wipes it clean and resyncs it with production — you’d lose your testing work.
Not required just to update and redeploy a change set.

B. Clone the change set and re-deploy ❌
Cloning creates a new copy, but that’s unnecessary. You can simply update the existing one.
Cloning is more useful if you want a different version for another environment, not when you’re updating an existing deployment path.

C. Rename the change set, add the changes, and re-deploy ❌
Renaming does nothing functionally.
Deployment depends on the contents of the change set, not its name.

📖 Reference:
Salesforce Help: Upload Outbound Change Sets
Trailhead: Change Set Development Model

Explanation:

The app builder should provision a Partial Data sandbox to the developer. A Partial Data sandbox can have up to 5 GB of data, which meets the requirement of having at least half a gigabyte of data. A Partial Data sandbox can also be refreshed every 5 days, which meets the requirement of refreshing after each three-day sprint.

Option A is incorrect because a Developer sandbox can only have up to 200 MB of data, which does not meet the requirement.
Option B is incorrect because a Full Copy sandbox can only be refreshed every 29 days, which does not meet the requirement.
Option C is incorrect because a Developer Pro sandbox can only have up to 1 GB of data, which may not be enough for the requirement.

Explanation:

When importing Opportunities (or any other object that can use a currency) into a multi-currency org, it is critical to specify which currency each record should use. The standard CurrencyIsoCode field is used for this purpose.

Option C is correct:
The import file must include a column for the CurrencyIsoCode field. This column should contain the 3-letter ISO currency code (e.g., 'USD', 'EUR', 'GBP') for each record. This tells Salesforce which currency the Amount field on that specific Opportunity is in.

Option B is correct:
Data Loader is the appropriate tool for this import. It provides the flexibility to map the CurrencyIsoCode field from the import file to the corresponding field in Salesforce. The Import Wizard has more limitations and is generally not recommended for complex data models or for objects that require specific field mappings like CurrencyIsoCode.

Option A is incorrect:
You do not modify the actual currency Amount field itself to include the ISO code. The Amount field should contain only the numeric value (e.g., 1000.00). The association of that number to a currency is handled by the separate CurrencyIsoCode field.

Option D is incorrect:
This option is grammatically incorrect and nonsensical ("Use Import the currency ISO Code Column"). It seems to be a malformed repetition of the correct concept from option C.

Option E is incorrect:
The Import Wizard is a simpler, UI-based tool that is best for importing standard objects with simple data mappings. It is less suited for a multi-currency import where you need to ensure precise mapping of the CurrencyIsoCode field, making Data Loader the more reliable and powerful choice.

Reference:
Salesforce Help: "Enable Multiple Currencies" - Overview of the feature.
Salesforce Help: "Considerations for Working with Currency Fields" - Explains how currency data is handled, including the role of the CurrencyIsoCode field.
Salesforce Help: "Import Data with the Data Import Wizard" vs. "Import Data with Data Loader" - The documentation for these tools highlights the advanced capabilities of Data Loader for complex data operations.

Explanation:

Changing the data type of a field used in an apex class from number to text will require the app builder to perform additional steps in order to retain existing functionalities. This is because changing the data type of a field may affect the apex code that references or manipulates the field value, and may cause compilation errors or unexpected results. The app builder will need to update the apex code to handle the new data type and ensure that the logic and calculations are still correct.

Option B is incorrect because changing the data type of a field used in a report from a text to an encrypted field will not require additional steps, as encrypted fields can still be used in reports with some limitations.
Option C is incorrect because changing the data type of a field used as an external id from number to text will not require additional steps, as external id fields can be either number or text.
Option D is incorrect because changing the data type of a field used in lead conversion from number to text will not require additional steps, as lead conversion fields can be mapped regardless of their data types.

Explanation:

Service agents at Ursa Major Solar need a more condensed case view and the ability to modify associated Contact and Account records directly from the Case page layout on a Lightning record page. The following components meet these requirements:

C. Related Record:
The Related Record component allows users to view and edit related records (e.g., Contact or Account) directly on the Case page without navigating away. By adding this component and configuring it to display the associated Contact and Account, service agents can modify key fields (e.g., phone number, email) inline, meeting the requirement for editing from the Case layout. This also helps condense the view by reducing the need for separate page navigation.
D. Tabs:
The Tabs component enables the app builder to organize sections of the Case page (e.g., Case Details, Contact Info, Account Info) into collapsible or switchable tabs. This condenses the layout by grouping related information, making it easier for agents to focus on essential data without overwhelming the screen, thus supporting the condensed view requirement.

Why not the other options?
A. Path:
The Path component provides guided navigation for record stages (e.g., Case Status progression) but does not facilitate editing related records or condensing the layout beyond its specific guidance role. It’s unrelated to the core requirements.
B. Rich Text:
The Rich Text component allows adding formatted text or images to the page but does not support editing related records or condensing the view. It’s a static display tool, not a functional solution for this scenario.

Implementation Notes:
Add the Related Record component to the Case Lightning page, configure it for Contact and Account with editable fields (e.g., via Field Sets or custom layout), and ensure the component visibility aligns with agent permissions.
Add the Tabs component, create tab sections (e.g., "Case," "Contact," "Account"), and assign relevant components or fields to each tab for a condensed, organized layout.
Test the page in Lightning App Builder to ensure usability on both desktop and mobile.

References:
Salesforce Help: Related Record Component (Details editing related records).
Salesforce Help: Tabs Component (Explains layout organization).
Salesforce Trailhead: Customize a Lightning Page (Covers component usage).