Praxis Academy
Inicio › Platform Administrator II › Security and Access

Preguntas de práctica Platform Administrator II: Security and Access

Security and Access vale 20% del examen Salesforce Certified Platform Administrator II. Cubre sharing avanzado, restriction rules, territorios y seguridad de sesión. Resuelve estas 7 preguntas gratis y abre cada respuesta para ver por qué cada opción es correcta o incorrecta.

01

En una org donde el OWD de Opportunity es Private, los representantes de ventas indican que pueden ver oportunidades que no les pertenecen, aunque no existe ningún Sharing Rule explícito. El administrador confirma que 'Grant Access Using Hierarchies' está activado. ¿Qué explica mejor este acceso?

  1. Con 'Grant Access Using Hierarchies' activado, los usuarios en roles superiores al propietario de un registro reciben automáticamente al menos acceso de lectura a los registros de los usuarios que están por debajo de ellos.
  2. Durante la configuración de la org se generó automáticamente una regla de uso compartido manual que da acceso de lectura a todos los usuarios internos.
  3. Cuando no existe ningún Sharing Rule, los registros de Opportunity pasan a Public Read/Write, lo que anula el OWD Private.
  4. Los perfiles de los representantes incluyen el permiso de sistema 'View All Data', que tiene prioridad sobre el OWD.
Ver respuesta

Respuesta: A

A. Con 'Grant Access Using Hierarchies' activado, los usuarios en roles superiores al propietario de un registro reciben automáticamente al menos acceso de lectura a los registros de los usuarios que están por debajo de ellos. ✓Correcta. La Role Hierarchy transmite la visibilidad de los registros hacia arriba, por lo que los usuarios en roles superiores ven los registros de sus subordinados pese al OWD Private.
B. Durante la configuración de la org se generó automáticamente una regla de uso compartido manual que da acceso de lectura a todos los usuarios internos.Incorrecta. La configuración de una org nunca crea uso compartido manual de forma automática, así que el acceso no proviene de ahí.
C. Cuando no existe ningún Sharing Rule, los registros de Opportunity pasan a Public Read/Write, lo que anula el OWD Private.Incorrecta. La ausencia de Sharing Rules no modifica el OWD; la configuración Private sigue vigente.
D. Los perfiles de los representantes incluyen el permiso de sistema 'View All Data', que tiene prioridad sobre el OWD.Incorrecta. 'View All Data' sí otorgaría visibilidad, pero el administrador atribuyó el acceso a 'Grant Access Using Hierarchies', no a un permiso del perfil.

Por qué: En objetos cuyo OWD es Private o Public Read Only, 'Grant Access Using Hierarchies' abre los registros a los usuarios ubicados más arriba en la Role Hierarchy que el propietario. Siempre está activo en los objetos estándar y solo puede desactivarse en objetos personalizados; en ese caso, el acceso se limita al propietario y a quienes se haya compartido el registro de forma explícita.

02

Un objeto con información financiera sensible tiene un OWD Public Read Only; sin embargo, los datos financieros solo deben ser visibles para los usuarios del rol 'Finance' y superiores en la Role Hierarchy. ¿Qué enfoque aplica correctamente esta restricción?

  1. Cambiar el OWD del objeto a Private y agregar un Sharing Rule basado en roles que comparta los registros con el rol 'Finance' y sus subordinados.
  2. Mantener el OWD en Public Read Only y usar Field-Level Security para ocultar los campos financieros sensibles a todos los perfiles excepto el perfil Finance.
  3. Agregar un Criteria-Based Sharing Rule que dé al rol 'Finance' acceso a los registros que cumplan un criterio de sensibilidad financiera.
  4. Activar Shield Platform Encryption en los campos financieros y entregar las claves de descifrado solo al perfil Finance.
Ver respuesta

Respuesta: B

A. Cambiar el OWD del objeto a Private y agregar un Sharing Rule basado en roles que comparta los registros con el rol 'Finance' y sus subordinados.Incorrecta. Pasar a Private y agregar un Sharing Rule para Finance cambia el acceso a los registros para todos; el requisito se refiere a datos sensibles dentro de registros que deben seguir siendo legibles en general.
B. Mantener el OWD en Public Read Only y usar Field-Level Security para ocultar los campos financieros sensibles a todos los perfiles excepto el perfil Finance. ✓Correcta. El acceso a los registros ya está abierto para todos, así que FLS es el control adecuado: ocultar los campos sensibles a todos los perfiles excepto Finance.
C. Agregar un Criteria-Based Sharing Rule que dé al rol 'Finance' acceso a los registros que cumplan un criterio de sensibilidad financiera.Incorrecta. Los Sharing Rules solo agregan acceso; no pueden quitar el acceso de lectura que ya otorga Public Read Only.
D. Activar Shield Platform Encryption en los campos financieros y entregar las claves de descifrado solo al perfil Finance.Incorrecta. Shield Platform Encryption protege los datos en reposo por cumplimiento normativo; no es un control de acceso por perfil, y cualquiera con visibilidad del campo puede leer los valores.

Por qué: La seguridad de Salesforce funciona en dos capas: acceso a registros (OWD, Sharing Rules, Role Hierarchy) y acceso a campos (Field-Level Security). Cuando todos ya pueden ver los registros con Public Read Only, ocultar datos específicos requiere FLS. Ocultar los campos financieros a los perfiles que no son de Finance permite que los demás usuarios abran el registro sin ver esos valores.

03

El OWD de Contact es Private; aun así, los usuarios con el perfil 'Contractor' pueden ver todos los contactos. El administrador revisa los Sharing Rules y no encuentra ninguno que otorgue ese acceso. ¿Cuál es la causa más probable?

  1. Se creó automáticamente un grupo público llamado 'All Contractors' y se incluyó en un Sharing Rule que expone los Contacts.
  2. Como el OWD del Account relacionado es Public Read/Write, se anula el OWD Private de Contact y los Contacts heredan el acceso de la cuenta.
  3. Los usuarios Contractor tienen el rol más alto de la Role Hierarchy, lo que les muestra automáticamente todos los registros por debajo de ellos.
  4. El perfil Contractor tiene activado el permiso de objeto 'Read All' en Contact, que omite el OWD de ese objeto.
Ver respuesta

Respuesta: D

A. Se creó automáticamente un grupo público llamado 'All Contractors' y se incluyó en un Sharing Rule que expone los Contacts.Incorrecta. Salesforce nunca crea por su cuenta grupos públicos ni Sharing Rules para perfiles, y la revisión del administrador no encontró ninguna regla así.
B. Como el OWD del Account relacionado es Public Read/Write, se anula el OWD Private de Contact y los Contacts heredan el acceso de la cuenta.Incorrecta. Un OWD Private en Contact es independiente del OWD de Account; la herencia solo ocurre cuando Contact está en 'Controlled by Parent', que es otra configuración.
C. Los usuarios Contractor tienen el rol más alto de la Role Hierarchy, lo que les muestra automáticamente todos los registros por debajo de ellos.Incorrecta. Nada indica que los usuarios Contractor tengan un rol alto, y el acceso por jerarquía solo cubriría los registros de usuarios en roles inferiores.
D. El perfil Contractor tiene activado el permiso de objeto 'Read All' en Contact, que omite el OWD de ese objeto. ✓Correcta. Un permiso de objeto del tipo 'View All' en Contact para el perfil Contractor daría acceso a todos los contactos sin importar el OWD ni el uso compartido, lo que coincide con lo observado.

Por qué: Un permiso de objeto como 'View All' en un perfil o Permission Set ignora el OWD y el uso compartido de ese objeto y da acceso de lectura a todos sus registros. Cuando un OWD Private no coincide con lo que los usuarios realmente ven, lo primero que hay que revisar es la configuración de objetos del perfil. Estos permisos deben controlarse con rigor porque eluden el modelo de uso compartido.

04

Un administrador crea un Login Flow que se ejecuta cuando los usuarios inician sesión desde fuera de la red corporativa e incluye un paso de Screen Flow que recopila datos de verificación adicionales. Después, algunos usuarios lo evitan al conectarse mediante la API. ¿Por qué ocurre esto?

  1. El acceso por API necesita su propio Login Flow, que debe configurarse específicamente para usuarios de API en la configuración de Login Flow solo para API.
  2. El Login Flow no se guardó correctamente; los cambios en Login Flows requieren borrar la caché de la página antes de aplicarse a los usuarios de API.
  3. Los Login Flows solo se aplican a inicios de sesión por interfaz de usuario; el acceso por API los omite por diseño, porque las sesiones de API no pueden ejecutar pasos de verificación interactivos con pantallas.
  4. Los usuarios que evitan el flujo usan una Connected App con el permiso 'Bypass Login Flow' activado, que debe desactivarse.
Ver respuesta

Respuesta: C

A. El acceso por API necesita su propio Login Flow, que debe configurarse específicamente para usuarios de API en la configuración de Login Flow solo para API.Incorrecta. No existe una configuración de Login Flow solo para API; los Login Flows son exclusivos de la interfaz de usuario por diseño.
B. El Login Flow no se guardó correctamente; los cambios en Login Flows requieren borrar la caché de la página antes de aplicarse a los usuarios de API.Incorrecta. El comportamiento es intencional para las sesiones de API, no un problema de guardado ni de caché.
C. Los Login Flows solo se aplican a inicios de sesión por interfaz de usuario; el acceso por API los omite por diseño, porque las sesiones de API no pueden ejecutar pasos de verificación interactivos con pantallas. ✓Correcta. Las llamadas SOAP/REST con tokens OAuth nunca pasan por el Login Flow porque las sesiones de API no pueden mostrar pantallas, una característica de diseño que los administradores deben considerar.
D. Los usuarios que evitan el flujo usan una Connected App con el permiso 'Bypass Login Flow' activado, que debe desactivarse.Incorrecta. La configuración de una Connected App puede influir en las sesiones, pero la causa de fondo es el diseño de la plataforma, no un permiso 'Bypass Login Flow'.

Por qué: Los Login Flows solo se ejecutan en inicios de sesión interactivos desde el navegador. Los clientes de API se autentican con tokens OAuth o con llamadas de usuario y contraseña a la API y no pueden mostrar pantallas, así que nunca pasan por un Login Flow. Para controlar el acceso por API se usan restricciones de IP, políticas OAuth de las Connected Apps y otros controles específicos de API.

05

En una org con 5,000 usuarios en varios países, un administrador que revisa los perfiles nota que muchos usuarios tienen el permiso 'Manage Users' sin necesitarlo. ¿Qué riesgo implica esto?

  1. Los usuarios con 'Manage Users' pueden crear, editar, desactivar y eliminar registros de usuario, restablecer contraseñas y cambiar asignaciones de rol y perfil, lo que podría permitirles darse a sí mismos o a otros un acceso elevado.
  2. Los usuarios con 'Manage Users' pueden ver todos los datos de la org sin importar el OWD ni los Sharing Rules, porque el permiso incluye implícitamente 'View All Data.'
  3. Los usuarios con 'Manage Users' pueden cambiar los Governor Limits y la configuración de ejecución de Apex, lo que genera un riesgo de desarrollo.
  4. Los usuarios con 'Manage Users' pueden eliminar todos los registros de la org, porque el permiso incluye 'Modify All Data.'
Ver respuesta

Respuesta: A

A. Los usuarios con 'Manage Users' pueden crear, editar, desactivar y eliminar registros de usuario, restablecer contraseñas y cambiar asignaciones de rol y perfil, lo que podría permitirles darse a sí mismos o a otros un acceso elevado. ✓Correcta. Como el permiso controla la configuración de usuarios, la asignación de roles y perfiles y los Permission Sets, su mal uso podría escalar privilegios o crear cuentas no autorizadas.
B. Los usuarios con 'Manage Users' pueden ver todos los datos de la org sin importar el OWD ni los Sharing Rules, porque el permiso incluye implícitamente 'View All Data.'Incorrecta. 'Manage Users' abarca la configuración de usuarios, no el acceso a los datos de los objetos.
C. Los usuarios con 'Manage Users' pueden cambiar los Governor Limits y la configuración de ejecución de Apex, lo que genera un riesgo de desarrollo.Incorrecta. Los Governor Limits los impone la plataforma y ningún permiso de administrador puede cambiarlos, incluido 'Manage Users'.
D. Los usuarios con 'Manage Users' pueden eliminar todos los registros de la org, porque el permiso incluye 'Modify All Data.'Incorrecta. 'Modify All Data' es un permiso distinto; 'Manage Users' no lo incluye.

Por qué: 'Manage Users' es un permiso de sistema muy poderoso: quien lo tiene puede crear y editar usuarios, restablecer contraseñas, desactivar cuentas y asignar roles, perfiles y Permission Sets, es decir, decide quién accede a qué. Repartirlo ampliamente favorece la escalada de privilegios, por lo que debe limitarse a administradores designados.

06

Un empleado está por dejar la empresa. El administrador debe bloquear su acceso a Salesforce y, a la vez, conservar todos sus registros y datos para reasignarlos. ¿Qué debe hacer el administrador?

  1. Eliminar el registro de usuario del empleado en Salesforce para terminar el acceso y liberar de inmediato todas las licencias asociadas.
  2. Desactivar el registro de usuario en Salesforce, lo que impide de inmediato el inicio de sesión, conserva todos los registros propiedad del usuario y libera la licencia para reasignarla.
  3. Quitar al empleado todos los Permission Sets y el perfil, dejando la cuenta activa pero sin acceso a ninguna función de Salesforce.
  4. Congelar la cuenta por ahora en lugar de desactivarla, para dar tiempo a reasignar los datos antes de terminar el acceso de forma permanente.
Ver respuesta

Respuesta: B

A. Eliminar el registro de usuario del empleado en Salesforce para terminar el acceso y liberar de inmediato todas las licencias asociadas.Incorrecta. En Salesforce no se pueden eliminar registros de usuario; el proceso admitido es la desactivación.
B. Desactivar el registro de usuario en Salesforce, lo que impide de inmediato el inicio de sesión, conserva todos los registros propiedad del usuario y libera la licencia para reasignarla. ✓Correcta. Desactivar bloquea el inicio de sesión de inmediato, conserva todo lo que pertenecía al usuario y libera la licencia; los registros pueden reasignarse con Mass Transfer Records.
C. Quitar al empleado todos los Permission Sets y el perfil, dejando la cuenta activa pero sin acceso a ninguna función de Salesforce.Incorrecta. El Profile es un campo obligatorio del registro de usuario, y dejar la cuenta activa sigue dejando una posible vía de acceso.
D. Congelar la cuenta por ahora en lugar de desactivarla, para dar tiempo a reasignar los datos antes de terminar el acceso de forma permanente.Incorrecta. Congelar solo bloquea el inicio de sesión de forma temporal y mantiene la licencia ocupada; para alguien que se va, la desactivación es el paso permanente adecuado.

Por qué: La desactivación es el paso estándar de salida: el inicio de sesión se bloquea de inmediato, se conservan todos los registros, el historial y los datos del usuario, y la licencia queda disponible para otra persona. Después, los registros pueden transferirse con Mass Transfer Records en Setup. Los usuarios no se pueden eliminar, solo desactivar.

07

Los Cases tienen un OWD Private. Un grupo de socios externos que usa un sitio de Experience Cloud debe poder ver los Cases vinculados a su propio Account. ¿Qué mecanismo de uso compartido es el más adecuado para dar a estos socios acceso a los Cases relacionados?

  1. Crear un Criteria-Based Sharing Rule que comparta los Cases con el perfil de la comunidad de socios cuando el Account del Case coincida con el Account del socio.
  2. Configurar un Sharing Set para el sitio de Experience Cloud que otorgue acceso a los Cases a usuarios externos cuando el campo Account del Case coincida con el Account del usuario socio.
  3. Agrupar a todos los usuarios socios en un grupo público y crear un Sharing Rule basado en propietario que comparta todos los Cases propiedad de cuentas de la comunidad de socios.
  4. Cambiar el OWD de Case a Public Read Only para que todos los usuarios, incluidos los socios, vean todos los Cases de la org.
Ver respuesta

Respuesta: B

A. Crear un Criteria-Based Sharing Rule que comparta los Cases con el perfil de la comunidad de socios cuando el Account del Case coincida con el Account del socio.Incorrecta. Las reglas basadas en criterios no pueden comparar un campo del Case con el Account propio de cada socio, así que no acotan el acceso de forma dinámica por socio.
B. Configurar un Sharing Set para el sitio de Experience Cloud que otorgue acceso a los Cases a usuarios externos cuando el campo Account del Case coincida con el Account del usuario socio. ✓Correcta. Un Sharing Set compara el campo Account del Case con el Account del usuario externo, de modo que cada socio ve solo los Cases de su propio Account.
C. Agrupar a todos los usuarios socios en un grupo público y crear un Sharing Rule basado en propietario que comparta todos los Cases propiedad de cuentas de la comunidad de socios.Incorrecta. Las reglas basadas en propietario comparten según el propietario del registro, no según un campo Account relacionado, así que no limitan a cada socio a sus propios Cases.
D. Cambiar el OWD de Case a Public Read Only para que todos los usuarios, incluidos los socios, vean todos los Cases de la org.Incorrecta. Un OWD Public Read Only expondría todos los Cases a todos los socios, una grave violación de privacidad.

Por qué: Los Sharing Sets son una función de Experience Cloud que da a los usuarios externos acceso a registros cuando un campo de búsqueda del registro, como Account en Case, coincide con el Account o Contact del propio usuario externo. Acotan el acceso por cuenta de forma dinámica y son el enfoque estándar para este tipo de uso compartido en portales.

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