Praxis Academy
Inicio › Platform App Builder › App Deployment

Preguntas de práctica Platform App Builder: App Deployment

App Deployment vale 13% del examen Salesforce Certified Platform App Builder. Cubre sandboxes, change sets, paquetes y DevOps Center. Resuelve estas 9 preguntas gratis y abre cada respuesta para ver por qué cada opción es correcta o incorrecta.

01

Un app builder de una tienda de artículos para exteriores creó un sandbox template que abarca Accounts, Projects y Project Milestones para rediseñar algunos flujos de la app de gestión de proyectos. ¿Qué tipo de entorno de pruebas debe crearse?

  1. Developer Pro
  2. Partial Copy
  3. Scratch Org
  4. Developer
Ver respuesta

Respuesta: B

A. Developer ProIncorrecta. Un Sandbox Developer Pro copia solo metadatos y no usa sandbox templates.
B. Partial Copy ✓Correcta. Los Sandboxes Partial Copy aplican un sandbox template para copiar datos de muestra de los objetos seleccionados.
C. Scratch OrgIncorrecta. Los scratch orgs son entornos temporales basados en código fuente y sin sandbox templates.
D. DeveloperIncorrecta. Un Sandbox Developer copia solo metadatos y no usa sandbox templates.

Por qué: Los sandbox templates eligen qué objetos reciben una muestra de los datos de producción en el Sandbox. Entre las opciones, solo un Sandbox Partial Copy usa templates, por lo que es el entorno que trae datos de Accounts, Projects y Project Milestones y permite probar los flujos con registros realistas sin copiar toda la base de datos. Referencia: Create or Edit Sandbox Templates

02

Un Platform App Builder implementó un Change Set desde un Sandbox a producción y la implementación está tardando muchísimo. ¿Qué explica el retraso?

  1. El Change Set contiene campos dependientes.
  2. El Change Set contiene Profiles.
  3. El Change Set contiene un cambio en el tipo de un campo.
  4. El Change Set contiene Roles.
Ver respuesta

Respuesta: C

A. El Change Set contiene campos dependientes.Incorrecta. Las definiciones de campos dependientes son metadatos ligeros y no ralentizan la implementación.
B. El Change Set contiene Profiles.Incorrecta. Los Profiles contienen configuraciones de permisos y no provocan conversión de datos.
C. El Change Set contiene un cambio en el tipo de un campo. ✓Correcta. Un cambio de tipo de datos exige convertir los valores existentes en cada registro, lo que puede hacer lenta la implementación.
D. El Change Set contiene Roles.Incorrecta. Los Roles son metadatos ligeros y no ralentizan la implementación.

Por qué: Cambiar el tipo de datos de un campo obliga a Salesforce a convertir cada valor ya almacenado en ese campo en todos los registros. Cuantos más registros tengan datos en el campo, más tarda la conversión y, por lo tanto, la implementación. La mayoría de los demás metadatos, como Profiles, Roles o definiciones de campos dependientes, no requiere conversión de datos. Referencia: Change Sets Best Practices

03

Un Platform App Builder debe configurar un Sandbox para un desarrollador que hará pruebas con conjuntos de datos de muestra considerables que requieren hasta 250 MB de almacenamiento. El Sandbox se actualizará a diario. ¿Qué tipo de Sandbox es el adecuado?

  1. Full
  2. Developer
  3. Partial Copy
  4. Developer Pro
Ver respuesta

Respuesta: D

A. FullIncorrecta. Un Sandbox Full solo puede actualizarse cada 29 días.
B. DeveloperIncorrecta. Un Sandbox Developer llega como máximo a 200 MB de datos.
C. Partial CopyIncorrecta. Un Sandbox Partial Copy solo puede actualizarse cada 5 días.
D. Developer Pro ✓Correcta. Developer Pro ofrece 1 GB de almacenamiento de datos y admite actualizaciones diarias.

Por qué: Un Sandbox Developer Pro ofrece 1 GB de almacenamiento de datos, suficiente para 250 MB, mientras que un Sandbox Developer se limita a 200 MB. Developer Pro también puede actualizarse una vez al día. Partial Copy (cada 5 días) y Full (cada 29 días) no cumplen el requisito de actualización diaria. Referencia: Sandbox Types and Templates

04

Un Platform App Builder de una tienda de equipo para actividades al aire libre terminó un nuevo flujo de cálculo de comisiones, junto con sus componentes de soporte, en un Developer sandbox. El líder del proyecto exige que los usuarios de operaciones de ventas confirmen el cálculo con datos reales de Opportunity antes de que algo pase a producción. Hay un Full sandbox disponible. ¿Qué enfoque de implementación debe seguir el app builder?

  1. Usar un change set con la opción Validate Only para enviar los componentes del Developer sandbox a producción y luego ejecutar User Acceptance Testing (UAT) en producción.
  2. Actualizar (refresh) el Developer sandbox desde producción para que reciba datos reales de Opportunity, ejecutar ahí User Acceptance Testing (UAT) y luego implementar en producción.
  3. Mover los componentes del Developer sandbox directamente a producción y dejar que los usuarios de operaciones de ventas los verifiquen en producción.
  4. Mover los componentes del Developer sandbox al Full sandbox, ejecutar User Acceptance Testing (UAT) en el Full sandbox y luego implementar en producción.
Ver respuesta

Respuesta: D

A. Usar un change set con la opción Validate Only para enviar los componentes del Developer sandbox a producción y luego ejecutar User Acceptance Testing (UAT) en producción.Incorrecta. Validate Only no realiza ninguna implementación, y ejecutar UAT en producción pone en riesgo los datos en vivo.
B. Actualizar (refresh) el Developer sandbox desde producción para que reciba datos reales de Opportunity, ejecutar ahí User Acceptance Testing (UAT) y luego implementar en producción.Incorrecta. Actualizar un Developer sandbox solo trae metadatos, así que no llegan datos reales de Opportunity.
C. Mover los componentes del Developer sandbox directamente a producción y dejar que los usuarios de operaciones de ventas los verifiquen en producción.Incorrecta. Ir directo a producción omite el UAT y expone los datos del negocio a riesgos.
D. Mover los componentes del Developer sandbox al Full sandbox, ejecutar User Acceptance Testing (UAT) en el Full sandbox y luego implementar en producción. ✓Correcta. El Full sandbox contiene una copia de los datos de producción, por lo que operaciones de ventas puede probar con registros reales antes de implementar en producción.

Por qué: El flujo se construyó en un Developer sandbox, que no contiene registros reales de Opportunity, pero operaciones de ventas debe probarlo con datos reales antes de la salida a producción. Un Full sandbox es una réplica completa de producción, incluidos los datos. Promover los componentes ahí permite a los testers ejecutar UAT con Opportunities realistas sin tocar registros en vivo. Una vez aprobado el UAT, el cambio pasa a producción. Probar con datos realistas antes de una liberación a producción es la práctica recomendada documentada. Referencia: Change Sets

05

Un Platform App Builder de una empresa farmacéutica construyó una aplicación de HR Onboarding compuesta por objetos personalizados, Page Layouts, Lightning Record Pages y una clase de Apex. El trabajo está en un Developer sandbox de la org de producción de la empresa. Una subsidiaria de propiedad total opera su propia org de producción de Salesforce, que no tiene conexión de implementación con la org de producción de la matriz. El app builder necesita transferir la aplicación de HR Onboarding del Developer sandbox de la matriz a la org de producción de la subsidiaria para que pueda evaluarse. ¿Qué enfoque de implementación debe tomar el app builder?

  1. Actualizar uno de los sandboxes de la subsidiaria desde el Developer sandbox de la matriz y luego implementar desde ese sandbox con change sets.
  2. Crear un paquete no administrado (unmanaged package) en el Developer sandbox de la matriz e instalarlo en la org de producción de la subsidiaria mediante la URL de instalación.
  3. Cargar un outbound change set desde el Developer sandbox de la matriz a la org de producción de la subsidiaria.
  4. Crear un paquete administrado (managed package) en el Developer sandbox de la matriz e instalarlo en la org de producción de la subsidiaria mediante la URL de instalación.
Ver respuesta

Respuesta: B

A. Actualizar uno de los sandboxes de la subsidiaria desde el Developer sandbox de la matriz y luego implementar desde ese sandbox con change sets.Incorrecta. Un sandbox que pertenece a otra org no puede actualizarse desde la propia org.
B. Crear un paquete no administrado (unmanaged package) en el Developer sandbox de la matriz e instalarlo en la org de producción de la subsidiaria mediante la URL de instalación. ✓Correcta. Un unmanaged package se instala por URL sin conexión de implementación, y la org receptora puede editar todos los componentes.
C. Cargar un outbound change set desde el Developer sandbox de la matriz a la org de producción de la subsidiaria.Incorrecta. Los change sets dependen de una conexión de implementación entre orgs relacionadas, y aquí no existe ninguna.
D. Crear un paquete administrado (managed package) en el Developer sandbox de la matriz e instalarlo en la org de producción de la subsidiaria mediante la URL de instalación.Incorrecta. Los managed packages están pensados para distribuir y actualizar apps con propiedad intelectual protegida, algo que una transferencia única no necesita.

Por qué: La aplicación debe llegar a una org de producción separada y sin conexión, y solo para evaluación, no para distribución continua. Los change sets requieren una conexión de implementación entre orgs relacionadas, que aquí no existe. Los paquetes, en cambio, mueven metadatos entre orgs no relacionadas mediante una URL de instalación. Un unmanaged package es adecuado para una transferencia única de evaluación: la org que lo instala es dueña de los componentes y puede editarlos por completo, y no se requiere ruta de actualización ni protección de propiedad intelectual. Referencia: Ways to Distribute Your Application

06

Una empresa de energía renovable quiere probar código con un subconjunto de datos de producción menor a 5 GB y quiere actualizar ese sandbox cada fin de semana. ¿Qué tipo de sandbox cumple estas necesidades?

  1. Developer Pro
  2. Partial Copy
  3. Full Copy
  4. Developer
Ver respuesta

Respuesta: B

A. Developer ProIncorrecta. Los Developer Pro sandboxes no contienen datos de producción.
B. Partial Copy ✓Correcta. Contiene hasta 5 GB de datos de producción y puede actualizarse cada 5 días.
C. Full CopyIncorrecta. Un Full Copy sandbox copia todos los datos y solo permite actualizar cada 29 días.
D. DeveloperIncorrecta. Los Developer sandboxes no contienen datos de producción.

Por qué: Deben cumplirse dos requisitos: datos reales de producción de hasta 5 GB y una actualización semanal. Un Partial Copy sandbox contiene un subconjunto de datos de producción definido por plantilla, con un límite de almacenamiento de 5 GB, lo que cubre la necesidad de datos. Su intervalo mínimo de actualización es de 5 días, menor a una semana, así que se permiten las actualizaciones de fin de semana. Referencia: Sandbox Types and Templates | Salesforce Help

07

Un Platform App Builder de una empresa de biotecnología está por implementar una liberación desde un Full sandbox a producción. La implementación ejecuta la suite completa de pruebas de Apex, que tarda unos 30 minutos. El equipo reservó una ventana de cutover el sábado por la mañana y quiere que la implementación ocupe el menor tiempo posible de esa ventana. ¿Qué enfoque de implementación debe usar el app builder?

  1. Cargar el outbound change set cuando se abra la ventana de cutover y hacer clic en Deploy.
  2. Cargar el outbound change set durante la ventana de cutover y elegir Run Local Tests para acortar la implementación.
  3. Cargar el outbound change set, ejecutar Validate Only contra producción el día anterior al cutover y luego hacer clic en Quick Deploy cuando se abra la ventana de cutover.
  4. Cargar el outbound change set el día anterior al cutover y luego hacer clic en Deploy cuando se abra la ventana de cutover.
Ver respuesta

Respuesta: C

A. Cargar el outbound change set cuando se abra la ventana de cutover y hacer clic en Deploy.Incorrecta. Implementar dentro de la ventana ejecuta la suite completa de 30 minutos durante el cutover.
B. Cargar el outbound change set durante la ventana de cutover y elegir Run Local Tests para acortar la implementación.Incorrecta. Ejecutar solo pruebas locales podría no cumplir el requisito y aun así corre pruebas dentro de la ventana.
C. Cargar el outbound change set, ejecutar Validate Only contra producción el día anterior al cutover y luego hacer clic en Quick Deploy cuando se abra la ventana de cutover. ✓Correcta. Las pruebas se ejecutan durante la validación un día antes, y Quick Deploy (válido por 10 días) implementa en la ventana sin volver a ejecutarlas.
D. Cargar el outbound change set el día anterior al cutover y luego hacer clic en Deploy cuando se abra la ventana de cutover.Incorrecta. Cargar con anticipación no evita que las pruebas se ejecuten al hacer clic en Deploy.

Por qué: El equipo quiere sacar de la limitada ventana del sábado la ejecución de 30 minutos de pruebas de Apex. Validate Only compila el código y ejecuta la suite completa de pruebas contra producción sin implementar, así que cualquier falla aparece con tiempo suficiente para corregirla. Una validación exitosa sigue siendo válida hasta por 10 días, y Quick Deploy implementa después sin volver a ejecutar las pruebas, lo que hace rápido el paso dentro de la ventana. Referencia: Validate a Deployment (Quick Deploy)

08

Un app builder necesita un sandbox donde los usuarios puedan ejecutar pruebas de aceptación de usuario sobre las funciones más recientes de los desarrolladores. Debe contener aproximadamente 500MB de datos definidos mediante una plantilla y actualizarse cada semana. ¿Qué sandbox cumple estos requisitos?

  1. Full sandbox
  2. Developer Pro sandbox
  3. Developer sandbox
  4. Partial Copy sandbox
Ver respuesta

Respuesta: D

A. Full sandboxIncorrecta. Un Full sandbox copia todos los datos y solo permite actualizar cada 29 días.
B. Developer Pro sandboxIncorrecta. Los Developer Pro sandboxes no ofrecen datos basados en plantilla.
C. Developer sandboxIncorrecta. Los Developer sandboxes no ofrecen datos basados en plantilla y solo tienen 200 MB de almacenamiento.
D. Partial Copy sandbox ✓Correcta. Copia hasta 5 GB de datos mediante una plantilla y puede actualizarse cada 5 días.

Por qué: Tres pistas acotan la elección: datos cargados mediante una plantilla, unos 500MB de ellos y una actualización semanal. Un Partial Copy sandbox usa una plantilla de sandbox para copiar una muestra de datos de producción de objetos seleccionados y admite hasta 5GB, lo que cubre con holgura 500MB. Puede actualizarse cada 5 días, así que las actualizaciones semanales funcionan. Al tener datos realistas de producción y no solo metadatos, es el entorno recomendado para QA y UAT. Un Full sandbox copia todo y se actualiza con mucha menor frecuencia, y los Developer sandboxes no ofrecen datos basados en plantilla. Referencia: Sandbox Types and Templates | Salesforce Help

09

Algunos objetos personalizados de una org de producción almacenan información confidencial. El equipo necesita un sandbox que contenga registros de datos, excluya todos los objetos confidenciales y pueda actualizarse cada semana. ¿Qué debe hacer un app builder para cumplir estos requisitos?

  1. Crear un Developer Pro Sandbox y programar Data Loader para descargar datos de objetos seleccionados cada semana.
  2. Crear un Full Copy Sandbox y aplicar una plantilla de sandbox.
  3. Crear un Partial Copy Sandbox y aplicar una plantilla de sandbox.
  4. Crear un Developer Sandbox y programar Data Loader para descargar datos de objetos seleccionados cada semana.
Ver respuesta

Respuesta: C

A. Crear un Developer Pro Sandbox y programar Data Loader para descargar datos de objetos seleccionados cada semana.Incorrecta. Los Developer Pro sandboxes no contienen datos de producción ni admiten plantillas, y programar Data Loader es una solución manual.
B. Crear un Full Copy Sandbox y aplicar una plantilla de sandbox.Incorrecta. Los Full sandboxes sí admiten plantillas, pero solo pueden actualizarse cada 29 días, no cada semana.
C. Crear un Partial Copy Sandbox y aplicar una plantilla de sandbox. ✓Correcta. Con una plantilla copia datos solo de los objetos elegidos y puede actualizarse cada 5 días.
D. Crear un Developer Sandbox y programar Data Loader para descargar datos de objetos seleccionados cada semana.Incorrecta. Los Developer sandboxes no contienen datos de producción ni admiten plantillas.

Por qué: El sandbox debe contener registros reales, excluir los objetos confidenciales y admitir actualizaciones semanales. Un Partial Copy sandbox obtiene su subconjunto de datos de una plantilla de sandbox, en la que el app builder elige qué objetos incluir y puede dejar fuera los confidenciales. Puede actualizarse cada 5 días, lo que cubre una cadencia semanal. Un Full Copy sandbox solo se actualiza cada 29 días, y los Developer o Developer Pro sandboxes no traen datos de producción ni usan plantillas. Referencia: Sandbox Types and Templates | Salesforce Help

Descubre si estás listo para aprobar

Haz el diagnóstico gratis de Platform App Builder: 20 preguntas, sin cuenta. Después desbloquea las 241 preguntas, los exámenes de práctica completos y la guía de estudio.

Hacer el diagnóstico gratisVer planes

Otras secciones de este examen