Developing Solutions for Microsoft Azure

Según la documentación de Microsoft, Strong consistency proporciona linealizabilidad: las lecturas siempre devuelven la escritura confirmada más reciente. Tiene la latencia de escritura más alta porque los datos deben replicarse y confirmarse de forma síncrona entre regiones. Los cinco niveles, del más fuerte al más débil: Strong, Bounded Staleness, Session, Consistent Prefix, Eventual.

Por qué las opciones distractoras son incorrectas:

• Eventual: La consistencia más débil, con la latencia más baja y sin garantías de ordenamiento.
• Session: Nivel intermedio; garantiza lecturas/escrituras monotónicas solo dentro de una sesión de cliente.
• Bounded staleness: Casi tan fuerte como Strong, pero permite una ventana de retraso configurable (tiempo u operaciones).

Tip de examen: Conoce los cinco niveles en orden. Strong = linealizabilidad + latencia más alta. La latencia de escritura equivale a 2x RTT entre las regiones más lejanas.

Según la documentación de Microsoft, un trigger hace que una función se ejecute y define cómo se invoca. Cada función debe tener exactamente un trigger. Los bindings conectan funciones de forma declarativa con recursos externos para entrada/salida sin escribir código repetitivo de conexión. Una función puede tener varios bindings de entrada y salida, pero solo un trigger.

Por qué las opciones distractoras son incorrectas:

• 'Trigger envía datos hacia afuera; binding recibe hacia adentro': Está invertido: los triggers invocan la función; los bindings manejan I/O de datos en ambas direcciones.
• 'Lo mismo con nombres diferentes': Triggers y bindings tienen propósitos fundamentalmente distintos (invocación vs. conexión de datos).
• 'Triggers funcionan solo con HTTP': Los triggers admiten HTTP, timer, queue, blob, Cosmos DB, Event Hub y muchos más servicios.

Tip de examen: Un trigger por función (invocación). Se permiten varios bindings (I/O de datos). Los bindings son declarativos: no se necesita código de conexión con SDK.

Las system-assigned managed identities están ligadas al ciclo de vida de un solo recurso de Azure: se crean cuando se crea el recurso y se eliminan cuando el recurso se elimina (relación 1:1). Las user-assigned managed identities son recursos de Azure independientes, con su propio ciclo de vida, que pueden compartirse entre varios recursos (muchos a muchos). Análisis de los distractores: Ambos tipos son gratuitos: no hay diferencia de costo. Ambos admiten los mismos mecanismos de autenticación: no hay distinción entre certificado y secreto. Ambos pueden acceder a los mismos servicios de Azure mediante RBAC: el alcance del acceso depende de las asignaciones de roles, no del tipo de identidad. Ref: learn.microsoft.com/entra/identity/managed-identities-azure-resources/overview

La instrumentación automática (codeless attach) habilita el monitoreo con Application Insights sin ninguna modificación de código. En App Service, la habilitas desde el portal de Azure o la CLI. Recopila automáticamente telemetría de solicitudes, seguimiento de dependencias, registro de excepciones y contadores de rendimiento para .NET, Java, Node.js y Python. Análisis de los distractores: La instrumentación manual con el SDK requiere agregar paquetes de NuGet/npm y cambiar código. Los procesadores de telemetría personalizados requieren integración del SDK y código para filtrar o modificar la telemetría. El OpenTelemetry SDK también requiere cambios de código para configurar los exportadores. La instrumentación automática sacrifica profundidad de personalización a cambio de una configuración rápida y sin código. Ref: learn.microsoft.com/azure/azure-monitor/app/codeless-overview