App Deployment pdf Flashcards
How often can a Full Copy Sandbox be refreshed?
- Every 5 days
- Every day
- Every 30 days
- Every 29 days
Every 29 days
Ava has uploaded a Change Set but realizes that although she added her new custom object, she forgot to add the new custom fields! What is TRUE in this scenario?
- Any new custom object will automatically include the relevant fields, therefore no modifications are required
- Change Sets cannot be modified or cloned after upload, so a brand new Change Set will need to be created
- Change Set can be modified after they have been uploaded
- Change Sets cannot be modified once uploaded but can be cloned to create a new Change Set
Change Sets cannot be modified once uploaded but can be cloned to create a new Change Set
Once a Change Set has been uploaded it may no longer be
modified. However, a Change Set can be cloned and
modified, then the modified Change Set can be uploaded.
Dependencies such as new custom fields are not automatically added to a Change Set when you add a
custom object to a Change Set. Any related fields or other
customizations such as validation rules will need to be
added to the Change Set. You have the option to ‘View
Dependencies’ to locate related fields and so on.
Ava the Admin has created a brand new custom object in a sandbox, complete with custom fields, page layouts and validation rules. She creates an outbound Change Set that contains the custom object. What will be TRUE in this scenario?
- The custom object only will be deployed
- The custom object deployment will fail because of missing components
- The custom object and custom fields will be deployed
- The custom object, custom fields, page layouts and validation rules will be deployed
The custom object only will be deployed
A Developer at Cloudy Computing has created several components that need to be installed in various other Cloudy Computing Developer environments that are unrelated to their Production instance. The code in these components should not be protected and no upgrades will be required.
What type of package should they create?
- Developer Edition Package
- Apex Package
- Unmanaged Package
- Managed Package
Unmanaged Package
Cloudy Computing should use an unmanaged package.
Unmanaged packages are typically used to distribute opensource projects, code or templates. The code and
components can be edited once installed but an unmanaged
package is not upgradable.
Managed packages are typically created by Salesforce
Partners to distribute or sell Apps. Managed packages can
be sold in a number of ways, including selling access to the
managed package via subscriptions or licenses (similar to how you purchase Salesforce licenses).
Managed packages are, well, “managed” and can be
upgraded as new versions are released. However, the
source code is protected, allowing for property protection,
and cannot be modified.
There is no such feature as Apex Package or Developer
Edition Package.
You need a Sandbox with a copy of your metadata from Production, however you require 1GB for data storage and file storage. You do not need a copy of your data from Production. What type of Sandbox would be most appropriate?
- Full Copy Sandbox
- Partial Copy Sandbox
- Developer Sandbox
- Developer Pro Sandbox
Developer Pro Sandbox
Developer Pro Sandboxes are very similar to standard
Developer environments but have slightly higher storage
limits. They provide you with 1GB for both data storage and
file storage. The refresh limit stays at 1 day.
Developer Pro Sandboxes are only included with Unlimited &
Performance editions of Salesforce, but can be purchased
separately.
Since we don’t need any actual data from Production, we do
not need to use a Partial Copy or Full Copy Sandbox.
What happens during the ‘Build Release’ phase of a deployment?
- You develop the application according to the requirements gathered during the planning phase
- You test your changes in a production environment
- You aggregate all the assets into a single release artifact that will be deployed to production
- You deploy changes to production
You aggregate all the assets into a single release artifact that will be deployed to production
During the ‘Build Release’ phase ofthe application lifecycle,
you aggregate all the assets into a single release artifact
that will be deployed to production.
When you want to deploy a Change Set to a Production org, what type of change set should be created in your Developer Sandbox?
- Outbound Change Set
- External Change Set
- Production Change Set
- Inbound Change Set
Outbound Change Set
An Outbound Change Set is required to first. The Outbound
Change Set will then be deployed to the Production
environment. From the Production environment, you’ll
search for Inbound Change Sets (this contains the
Outbound Change Sets that have been pushed to this org).
Inbound Change Sets can then be deployed in Production.
Which of the following is TRUE about Change Sets? (Choose 2)
- Inbound Change Sets will be automatically deployed
- Inbound Change Sets must be validated
- Inbound Change Sets must be manually deployed
- Inbound Change Sets must meet a minimum of 70% code coverage
- Inbound Change Sets must be validated
- Inbound Change Sets must be manually deployed
You must run tests before you deploy an inbound Change
Set.
An inbound Change Set must meet a minimum of 75% code
coverage. Inbound Change Sets must be manually
deployed.
What is NOT a way to move changes from your Sandbox to Production instance?
- Lightning API
- Visual Studio Code
- Metadata API
- Change Sets
- ANT Migration Tool
Lightning API
What cannot be moved from a Sandbox to a Production environment using a Change Set?
- Apex Trigger
- Flows
- Sharing Rules
- Custom Fields
- Records
Records
What is TRUE about the deployment of Change Sets? (Choose 2)
- A successful deployment can be rolled back if required
- A successful deployment cannot be rolled back
- If a deployment is unable to complete for any reason, only successful components will be committed and failed components rolled back
- If a deployment is unable to complete for any reason, the entire transaction is rolled back
- A successful deployment cannot be rolled back
- If a deployment is unable to complete for any reason, the entire transaction is rolled back
Cloudy Computing has two Salesforce Administrators. Each Administrator is configuring their changes in individual Developer Sandboxes that have been created from the Production Org. The Junior Administrator’s changes need to be migrated to the Senior Administrator’s Developer Sandbox to be tested before all changes are moved to the Production Org. What are some considerations? (Choose 2)
- A deployment connection will automatically be established between the two Developer Sandboxes
- A deployment connection will need to be configured between the two Developer Sandboxes
- The Sandbox used by the Senior Administrator will need to allow inbound changes
- The Sandbox used by the Senior Administrator will need to allow outbound changes
- A deployment connection will need to be configured between the two Developer Sandboxes
- The Sandbox used by the Senior Administrator will need to allow inbound changes
Change Sets can only be deployed between Orgs that are
connected via a deployment connection. The deployment
connection will define whether inbound and/or outbound
changes are allowed
When you create a Sandbox from a Production instance, a
deployment connection is automatically established.
However, a deployment connection is not automatically
established between Sandboxes that were created from
the same Production instance, therefore this will need to be
configured.
The Sandbox used by the Senior Administrator will need to
allow inbound changes from the Junior Administrator’s
Developer Sandbox.
What happens if a Developer wishes to retire a package? (Choose 2)
- The ‘Retire’ button can be used to retire the application
- The ‘Deprecate’ button can be used to retire the application
- All installations (including those prior to retirement) will stop working
- No new installations will be possible once retired
- The ‘Deprecate’ button can be used to retire the application
- No new installations will be possible once retired
It is possible to use the ‘Deprecate’ button to retire an
application. Once an application is retired, no new installs
are possible but previous installations (prior to retirement)
will continue to work.
Which types of Sandboxes support Sandbox Templates? (Choose 2)
- Developer Pro Sandbox
- Developer Sandbox
- Partial Copy Sandbox
- Full Copy Sandbox
- Partial Copy Sandbox
- Full Copy Sandbox
What is NOT a test option for deploying Change Sets?
- Run No Tests
- Run Specified Tests
- Run All Tests
- Run Local Tests
- Default
Run No Tests
The test options for Change Sets are:
Default
Run Local Tests
Run All Tests
Run Specified Tests
You must select from these options before you deploy an
Inbound Change Set – there is no ‘Run No Tests’ option.
What statements are TRUE about managed packages? (Select 2)
- Managed packages do not allow for licensing
- Managed packages have open-source code
- Managed packages have upgradable components
- Managed packages allow for property protection
- Managed packages have upgradable components
- Managed packages allow for property protection
Managed packages are typically created by Salesforce
Partners to distribute or sell Apps. Managed packages can
be sold in a number of ways, including selling access to the
managed package via subscriptions or licenses (similar to
how you purchase Salesforce licenses).
Managed packages are, well, “managed” and can be
upgraded as new versions are released. However, the
source code is protected, allowing for property protection,
and cannot be modified.
Unmanaged packages are typically used to distribute opensource projects, code or templates. The code and
components can be edited once installed but an unmanaged
package is not upgradable.
What can be validated to see if a deployment will be successful or not?
- Developer Console
- Ant Migration Tool
- Visual Studio Code
- Change Sets
Change Sets
Change Sets can be validated ahead oftime to see if a deployment will be successful or not.
You would like to do some user acceptance testing and training in a Sandbox that contains some data from your Production environment. What type of Sandbox would be most appropriate for this task?
- Partial Copy Sandbox
- Full Copy Sandbox
- Developer Sandbox
- Developer Pro Sandbox
Partial Copy Sandbox
A Partial Copy Sandbox allows you to not only copy
metadata, but also a portion of your data. You can select a
sample set of data using a Sandbox Template.
This Sandbox is designed to be used for quality assurance
tasks such as user acceptance testing, integration testing,
and training.
What are some considerations about Salesforce org IDs in relation to Sandboxes? (Choose 2)
- The Organization ID will be the same for your Production and Sandbox instances
- The Organization ID will be different for your Production and Sandbox instances
- Hard coded IDs will not need to be updated when changes are deployed from a Sandbox to Production
- The org ID of your Sandbox changes each time your Sandbox is refreshed
- The Organization ID will be different for your Production and Sandbox instances
- The org ID of your Sandbox changes each time your Sandbox is refreshed
Your Salesforce Organization ID is the unique identifier for
your Salesforce instance. The Salesforce Organization ID
can be found on the Company Information page. The ID for
your Production instance will be different to your
Sandboxes.
The org ID of a Sandbox changes each time you refresh the
Sandbox. Any hard coded IDs will likely need to be updated
when changes are moved from a Sandbox into Production,
and therefore it is advisable to avoid hard coded IDs
wherever possible.
What can you do with a Change Set? (Choose 2)
- Rename a component
- Add changed components
- Delete a component
- Add new components
- Add changed components
- Add new components
you cannot rename or delete a component
using a Change Set
What is TRUE about change set deployment connections? (Choose 3)
- Sandboxes created from a Production Org automatically have a deployment connection set up
- Change Sets can be deployed between any Salesforce Orgs
- Deployment settings can define whether inbound and/or outbound changes are allowed
- You can only deploy Change Sets between Orgs that are connected by a deployment connection
- Sandboxes created from a Production Org automatically have a deployment connection set up
- Deployment settings can define whether inbound and/or outbound changes are allowed
- You can only deploy Change Sets between Orgs that are connected by a deployment connection
Change Sets can only be deployed between Orgs that are
connected via a deployment connection. The deployment
connection will define whether inbound and/or outbound
changes are allowed
When you create a Sandbox from a Production instance, a
deployment connection is automatically established.
