Praxis Academy
Inicio › Platform Administrator II › Environment Management and Deployment

Preguntas de práctica Platform Administrator II: Environment Management and Deployment

Environment Management and Deployment vale 7% del examen Salesforce Certified Platform Administrator II. Cubre tipos de sandbox, change sets, paquetes y DevOps Center. Resuelve estas 4 preguntas gratis y abre cada respuesta para ver por qué cada opción es correcta o incorrecta.

01

Un Full Sandbox se actualizó hace 28 días, y un gerente de proyecto quiere actualizarlo de nuevo de inmediato para incorporar configuración nueva para pruebas. ¿Qué debe comunicarle el administrador?

  1. Los Full Sandboxes deben esperar al menos 29 días entre actualizaciones, así que con solo 28 días transcurridos la actualización aún no puede iniciarse.
  2. Los Full Sandboxes pueden actualizarse cuando se necesite, porque el límite de 29 días aplica solo a los Partial Copy Sandboxes.
  3. Se requiere un caso con Salesforce Support para levantar la restricción de actualización en proyectos urgentes.
  4. La actualización se pondrá en cola sola y comenzará automáticamente al cumplirse exactamente 29 días, sin intervención del administrador.
Ver respuesta

Respuesta: A

A. Los Full Sandboxes deben esperar al menos 29 días entre actualizaciones, así que con solo 28 días transcurridos la actualización aún no puede iniciarse. ✓Correcta. Los Full Sandboxes tienen un intervalo mínimo de actualización de 29 días, por lo que el administrador debe esperar al menos un día más.
B. Los Full Sandboxes pueden actualizarse cuando se necesite, porque el límite de 29 días aplica solo a los Partial Copy Sandboxes.Incorrecta. El intervalo de 29 días corresponde a los Full Sandboxes; los Partial Copy Sandboxes usan un intervalo de 5 días.
C. Se requiere un caso con Salesforce Support para levantar la restricción de actualización en proyectos urgentes.Incorrecta. Un caso de soporte no es la vía normal para saltarse el intervalo; simplemente debe transcurrir.
D. La actualización se pondrá en cola sola y comenzará automáticamente al cumplirse exactamente 29 días, sin intervención del administrador.Incorrecta. Las actualizaciones nunca se ponen en cola automáticamente; el administrador las inicia manualmente una vez cumplido el intervalo.

Por qué: Los intervalos mínimos de actualización son 1 día para Developer y Developer Pro, 5 días para Partial Copy y 29 días para Full Sandboxes, que copian todos los datos y metadatos de producción. La opción de actualizar vuelve a estar disponible solo al llegar al día 29.

02

Al validar un Change Set de un Developer Sandbox hacia producción, aparece un error de que la cobertura de código de pruebas está por debajo del nivel requerido. ¿Qué dos afirmaciones describen correctamente las reglas de cobertura de código para despliegues a producción? (Elija 2)

  1. Las pruebas unitarias deben cubrir al menos el 75% de todo el código Apex de la org para un despliegue a producción.
  2. Cada trigger de Apex necesita al menos 1% de cobertura de código para formar parte de un despliegue a producción.
  3. Cada trigger de Apex de la org necesita algo de cobertura de pruebas (al menos un método de prueba debe ejecutarlo) para que el despliegue tenga éxito.
  4. Las pruebas de cobertura pueden omitirse en producción activando la opción 'Deploy without Running Tests' en la configuración del Change Set.
Ver respuesta

Respuesta: A, C

A. Las pruebas unitarias deben cubrir al menos el 75% de todo el código Apex de la org para un despliegue a producción. ✓Correcta. Al menos el 75% de las líneas de Apex debe estar cubierto antes de desplegar Apex a producción, medido sobre todo el Apex de la org, no solo el del Change Set.
B. Cada trigger de Apex necesita al menos 1% de cobertura de código para formar parte de un despliegue a producción.Incorrecta. La fuente plantea la regla de triggers como 'algo de cobertura' probada por al menos un método, no un umbral del 1%; la cifra del 75% es el requisito general de la org.
C. Cada trigger de Apex de la org necesita algo de cobertura de pruebas (al menos un método de prueba debe ejecutarlo) para que el despliegue tenga éxito. ✓Correcta. Además de la regla del 75% en toda la org, cada trigger debe tener algo de cobertura; un trigger en cero hace fallar el despliegue aunque la cobertura general supere el 75%.
D. Las pruebas de cobertura pueden omitirse en producción activando la opción 'Deploy without Running Tests' en la configuración del Change Set.Incorrecta. Según la fuente, omitir pruebas no está disponible para producción; los despliegues a producción siempre ejecutan pruebas y deben cumplir el umbral del 75%.

Por qué: Los despliegues a producción requieren dos cosas: al menos 75% de cobertura sobre todo el código Apex de la org (una cifra acumulada) y algo de cobertura en cada trigger de Apex. Un trigger con 0% bloquea el despliegue aunque la cobertura general sea de 75% o más. Las pruebas deben crear sus propios datos de prueba en lugar de depender de registros reales.

03

Un administrador crea un Flow programado (schedule-triggered) que debe ejecutarse cada noche a medianoche. Funciona en las pruebas del sandbox, pero después de desplegarlo a producción con un Change Set nunca se ejecuta. ¿Cuál es la explicación más probable?

  1. Los Change Sets no pueden transportar Scheduled Flows, así que deben reconstruirse a mano en producción.
  2. Los Change Sets despliegan los flows como Inactive; además, los Scheduled Flows deben activarse manualmente en producción y, en algunos casos, debe configurarse una nueva 'Start Date' para la programación después de activarlos.
  3. Tras un despliegue con Change Set, los Scheduled Flows se pausan 30 días mientras Salesforce compara la programación con las ventanas de mantenimiento.
  4. Las orgs de sandbox y producción usan zonas horarias distintas, así que la programación de medianoche nunca se dispara en la zona horaria de producción.
Ver respuesta

Respuesta: B

A. Los Change Sets no pueden transportar Scheduled Flows, así que deben reconstruirse a mano en producción.Incorrecta. Los Scheduled Flows se despliegan en Change Sets como metadatos de flow normales.
B. Los Change Sets despliegan los flows como Inactive; además, los Scheduled Flows deben activarse manualmente en producción y, en algunos casos, debe configurarse una nueva 'Start Date' para la programación después de activarlos. ✓Correcta. El Flow llega como Inactive y, en el caso de un Scheduled Flow, también puede ser necesario configurar o confirmar la fecha y hora de inicio después de activarlo.
C. Tras un despliegue con Change Set, los Scheduled Flows se pausan 30 días mientras Salesforce compara la programación con las ventanas de mantenimiento.Incorrecta. Salesforce no tiene una pausa de 30 días posterior al despliegue para los scheduled flows.
D. Las orgs de sandbox y producción usan zonas horarias distintas, así que la programación de medianoche nunca se dispara en la zona horaria de producción.Incorrecta. Las zonas horarias podrían cambiar el momento en que corre el Flow, pero un Flow que nunca se ejecuta apunta al estado Inactive tras el despliegue.

Por qué: Los Scheduled Flows necesitan dos pasos posteriores al despliegue: activar el Flow en la org destino (todo Flow desplegado llega como Inactive) y luego confirmar o configurar la fecha y hora de inicio de la programación en producción. Ambos deben estar en la lista de verificación del despliegue.

04

Se valida en producción un Change Set con clases y triggers de Apex personalizados. La cobertura de código general es de 80%, pero un trigger de Apex tiene 0% de cobertura. ¿Qué pasa con la validación?

  1. Pasa, porque la cobertura general supera el 75% y la cobertura por trigger no se revisa por separado.
  2. Falla, porque cada trigger de Apex de la org necesita algo de cobertura de código (más de 0%), aunque la cobertura general esté por encima del 75%.
  3. Pasa con una advertencia, permitiendo al administrador desplegar siempre que la cobertura se corrija en 30 días.
  4. Pasa en el sandbox y falla solo en producción, una limitación conocida de la plataforma Salesforce.
Ver respuesta

Respuesta: B

A. Pasa, porque la cobertura general supera el 75% y la cobertura por trigger no se revisa por separado.Incorrecta. La cobertura de los triggers se revisa por separado; un trigger con 0% hace fallar la validación y el despliegue sin importar la cobertura general.
B. Falla, porque cada trigger de Apex de la org necesita algo de cobertura de código (más de 0%), aunque la cobertura general esté por encima del 75%. ✓Correcta. Además de la regla general del 75%, Salesforce exige algo de cobertura en cada trigger, así que un trigger con 0% hace fallar la validación.
C. Pasa con una advertencia, permitiendo al administrador desplegar siempre que la cobertura se corrija en 30 días.Incorrecta. No existe una opción de advertencia con periodo de gracia; la cobertura de 0% en un trigger hace fallar la validación de inmediato.
D. Pasa en el sandbox y falla solo en producción, una limitación conocida de la plataforma Salesforce.Incorrecta. Según la fuente, la revisión de cobertura se aplica igual en ambos entornos; no es una discrepancia conocida entre sandbox y producción.

Por qué: El despliegue a producción aplica dos reglas de cobertura: al menos 75% sobre todo el Apex y más de 0% en cada trigger de Apex. Incumplir cualquiera hace fallar el despliegue, así que un solo trigger sin pruebas lo bloquea sin importar qué tan alta sea la cifra general.

Descubre si estás listo para aprobar

Haz el diagnóstico gratis de Platform Administrator II: 20 preguntas, sin cuenta. Después desbloquea las 180 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