Preguntas de entrevista para Ingeniero Cloud

Respuesta modelo

Diseñé la landing zone de una aseguradora que llegaba desde un modelo de dos cuentas compartidas por todos los equipos. Opté por una estructura multicuenta con AWS Control Tower y Organizations, con unidades organizativas separadas por entorno y criticidad, y una cuenta por equipo y entorno, porque el aislamiento de la explosión de un fallo y la imputación de costes son mucho más limpios con la frontera de la cuenta que con etiquetas y políticas dentro de una sola. Puse las barreras en el nivel preventivo con catorce Service Control Policies (bloqueo de regiones fuera de la Unión Europea, prohibición de desactivar CloudTrail o GuardDuty, y de crear usuarios IAM con claves permanentes) y dejé las reglas de AWS Config para el nivel detectivo, con corrección automática. Descarté un modelo de cuenta única con separación por VPC, porque los límites de servicio y los radios de impacto acaban compartidos, y descarté Control Tower personalizado en exceso, ya que cada desviación del camino estándar se paga en cada actualización del servicio. También descarté al principio la red hub and spoke por coste, y me equivoqué: a las dieciocho VPC los emparejamientos eran inmanejables y acabamos migrando a Transit Gateway seis meses después.

Respuesta modelo

Primero mido y atribuyo, porque sin atribución cualquier recorte es a ciegas. Cargo el informe de costes y uso en Athena y saco el desglose por cuenta, servicio y etiqueta, y comparo mes a mes para separar el crecimiento por uso del crecimiento por precio. Casi siempre aparecen tres bolsas: recursos huérfanos (volúmenes sin adjuntar, direcciones IP elásticas sin usar, copias antiguas, entornos de una prueba de concepto que nadie apagó), sobredimensionamiento, y transferencia de datos, que es la partida que más sorprende, sobre todo NAT Gateway y tráfico entre zonas de disponibilidad. Actúo por orden de retorno y de riesgo: primero lo que no tiene impacto (apagar lo que sobra, ciclo de vida en el almacenamiento, gp2 a gp3, endpoints en lugar de NAT); después el dimensionamiento a la baja con datos de al menos catorce días; y solo cuando la base de consumo es estable comprometo Savings Plans, empezando por una cobertura del 70 % y a un año, nunca al 100 %, para no quedar atrapado si la arquitectura cambia. Por último cierro el grifo: etiquetado obligatorio aplicado con SCP, presupuestos con alerta por cuenta y detección de anomalías, y un cuadro de mando mensual por unidad de negocio. En el caso real pasamos de 31.000 € a 21.400 € al mes en cuatro meses.

Respuesta modelo

Empiezo por separar tres cosas que suelen mezclarse: dónde residen los datos, quién puede acceder a ellos y cómo se demuestra. Para la residencia despliego en una región española (eu-south-2 en el caso de AWS, Spain Central en Azure) y bloqueo el resto con una política preventiva a nivel de organización, de forma que ni siquiera por error se pueda crear un recurso fuera; reviso además los servicios que replican o procesan datos fuera de la región por diseño y los sustituyo o los descarto. Para el acceso, cifro en reposo con claves gestionadas por el cliente, con la política de la clave como control real de quién puede descifrar, y trato el soporte del proveedor y el acceso de administradores como un riesgo que debe estar documentado. Para la demostración, que es donde se cae la mayoría de los proyectos, parto de la categorización del sistema conforme al Real Decreto 311/2022 y del anexo de medidas correspondiente a la categoría, me apoyo en las guías CCN-STIC aplicables a servicios en la nube, y automatizo la evidencia: registro de actividad centralizado en una cuenta de auditoría con retención acorde, reglas de configuración que comprueban de forma continua cada medida y un cuadro de conformidad exportable para el auditor. Y dejo por escrito la declaración de aplicabilidad y el reparto de responsabilidades con el proveedor, porque el modelo de responsabilidad compartida es siempre la primera pregunta de la auditoría.

Respuesta modelo

Nunca empiezo por mover máquinas, sino por el inventario y las dependencias, porque el riesgo real de una migración está en la conversación que nadie documentó entre dos sistemas. Uso herramientas de descubrimiento durante al menos cuatro semanas para capturar los flujos reales de red y la estacionalidad, y con eso clasifico cada carga según las siete erres: retirar lo que ya nadie usa, que suele ser entre el 10 y el 20 % del inventario y es el ahorro más rápido; retener lo que no puede moverse todavía por licencia, latencia o normativa; rehost para el grueso, porque mover primero y optimizar después reduce el riesgo del corte; replatform para lo que gana mucho con poco esfuerzo, típicamente bases de datos a servicio gestionado; y dejo el refactor para después de la migración, nunca durante. Después agrupo en oleadas por dominio de dependencias, empezando por una de baja criticidad que sirva de ensayo del proceso completo. Cada oleada tiene ventana acordada con negocio, criterios de aceptación medibles, plan de reversión probado y un periodo de convivencia con replicación inversa si la base de datos lo permite. Y la conectividad híbrida definitiva se monta antes de la primera oleada, no durante: en mi último proyecto, 96 servidores y 14 bases de datos Oracle en cinco oleadas, con cortes por debajo de dos horas y ninguna reversión.

Respuesta modelo

Yo respondo de la plataforma y del terreno sobre el que se construye: estructura de cuentas y barreras de seguridad, direccionamiento y conectividad con el centro de datos, identidad y cifrado, arquitectura de las cargas, coste y continuidad. Un ingeniero DevOps responde del camino que recorre un cambio hasta producción: pipelines, automatización de despliegue, calidad de la entrega y tiempo de recuperación del proceso. Nos solapamos en Terraform, en Kubernetes y en observabilidad, y en equipos pequeños es la misma persona, pero las preguntas que nos hacen son distintas: a mí me preguntan por qué esta red tiene este direccionamiento y qué pasa si cae una zona de disponibilidad; a un DevOps le preguntan por qué el despliegue tarda cuarenta minutos y cómo se revierte. En mi último equipo la frontera estaba clara: yo entregaba módulos de Terraform aprobados y una cuenta con las barreras puestas, y los equipos de producto desplegaban por sí mismos sobre esa base. Trabajo con gusto en los dos lados, pero el valor que aporto está en la arquitectura y en el gobierno.

Respuesta modelo

Asumo que si la esquivan es porque les estorba, así que empiezo preguntando en lugar de imponiendo. En mi último equipo la queja era que pedir un entorno tardaba nueve días, y tenían razón: el problema no era su resistencia, era mi cola de peticiones. Lo resolví publicando módulos de Terraform aprobados con valores por defecto seguros y una cuenta ya provista con las barreras puestas, de forma que pudieran crear lo que necesitaban sin pasar por mí. Las peticiones al equipo de plataforma bajaron de unas sesenta a dieciocho al mes y el plazo de entrega de un entorno pasó a menos de un día. Lo que no negocio son los controles preventivos, porque son requisito de auditoría, pero sí explico siempre por qué existe cada uno y ofrezco un camino alternativo cuando el control bloquea un caso legítimo. La regla que aplico es que el camino seguro tiene que ser también el camino más cómodo; si no lo es, la culpa es de la plataforma, no del equipo que la evita.

Parto de un bloque privado amplio reservado solo para la nube, por ejemplo un rango grande dentro de 10.0.0.0/8 que negocio con el equipo de redes corporativas para que no solape con el centro de datos ni con las delegaciones, porque un solape se paga después con traducción de direcciones y con dolor permanente. Reparto por región y por entorno en bloques contiguos, de modo que la agregación de rutas sea sencilla, y asigno a cada VPC un tamaño holgado, típicamente un /20, con subredes por zona de disponibilidad separadas en tres capas: pública, privada de aplicación y privada de datos. Conecto todo con Transit Gateway y no con emparejamientos, porque los emparejamientos no son transitivos y a partir de una docena de VPC la matriz es inmanejable; uso tablas de enrutamiento del propio Transit Gateway para segmentar, de forma que producción y desarrollo no se alcancen entre sí y ambos sí lleguen a los servicios compartidos. La salida a internet la centralizo en una VPC de inspección con firewall gestionado y NAT, lo que reduce el número de NAT Gateway y da un punto único de control y de registro. El acceso a servicios del proveedor lo resuelvo con endpoints de tipo interfaz y de tipo pasarela para S3 y DynamoDB, que además elimina coste de procesamiento de NAT. Para el híbrido monto dos Direct Connect de proveedores distintos, con VPN de respaldo y anuncios BGP con preferencia local para controlar la simetría del tráfico, y resuelvo el DNS con reglas de reenvío en ambos sentidos entre la zona privada y los servidores corporativos.

Es la base de una organización en la nube: la estructura de cuentas, la identidad, la red, la seguridad, la auditoría y el control de coste ya resueltos, de modo que un equipo pueda empezar a trabajar sin volver a decidir nada de eso ni cometer errores estructurales. Como mínimo incluye una organización con unidades organizativas separadas por entorno y criticidad, y cuentas dedicadas de gestión, de auditoría y registro, de seguridad y de red compartida. Acceso federado con el proveedor de identidad corporativo y roles con permisos temporales, en lugar de usuarios con claves permanentes. Barreras preventivas con Service Control Policies para lo innegociable, como impedir el despliegue fuera de las regiones autorizadas o el borrado de los registros de auditoría. Registro centralizado e inmutable de CloudTrail y de los registros de flujo de red en la cuenta de auditoría, con acceso separado. Red base con el direccionamiento planificado y la conectividad híbrida. Cifrado por defecto con claves gestionadas y una política clara. Etiquetado obligatorio, presupuestos y alertas de anomalía. Y un proceso automatizado de creación de cuentas, porque si dar de alta un entorno nuevo cuesta semanas, los equipos acabarán reutilizando cuentas ajenas y toda la estructura pierde el sentido. Todo ello descrito en código y versionado, no configurado a mano en la consola.

La alta disponibilidad protege frente al fallo de un componente o de una zona de disponibilidad dentro de la misma región y se resuelve con redundancia automática: instancias en varias zonas tras un balanceador, base de datos con réplica en espera en otra zona y conmutación automática, almacenamiento replicado por diseño. La recuperación ante desastres protege frente a la pérdida de la región entera o frente a un desastre lógico, como un borrado masivo o un cifrado por ransomware, e implica una decisión de negocio expresada en RTO y RPO. Las estrategias, de menor a mayor coste, son cuatro. Copia y restauración: solo copias replicadas a otra región, con RTO de horas o días, la más barata. Luz piloto: los datos replicados de forma continua y lo mínimo imprescindible encendido, con el resto definido en código y listo para levantar, con RTO de decenas de minutos a horas. Warm standby: una versión reducida del entorno funcionando de verdad en la segunda región, que se escala al conmutar, con RTO de minutos. Y activo-activo multirregión, con tráfico repartido y RTO casi nulo, que multiplica coste y complejidad, sobre todo por la consistencia de datos. Elijo según la criticidad de cada aplicación, y no la misma para todas. Lo esencial es que ninguna estrategia vale nada sin simulacros periódicos y sin copias inmutables aisladas: frente a un desastre lógico, la replicación continua replica también el desastre.

Elimino los usuarios con claves permanentes y federo contra el proveedor de identidad corporativo, en mi caso Microsoft Entra ID, mediante IAM Identity Center, de modo que el alta y la baja de una persona ocurran en un solo sitio, que es el directorio de la empresa, y la salida de un empleado cierre de verdad todos los accesos. Los permisos se conceden a grupos del directorio, nunca a personas, y se materializan como roles con credenciales temporales de duración corta. Aplico privilegio mínimo por capas: las Service Control Policies fijan el techo de lo que es posible en toda la unidad organizativa, las políticas de permisos conceden lo necesario dentro de ese techo, y los límites de permisos evitan la escalada cuando un equipo puede crear sus propios roles. Para las cargas de trabajo uso roles asumidos por el servicio y federación de identidad, de forma que no exista ni una sola clave de larga duración en un pipeline ni en un contenedor. El acceso administrativo a producción va con aprobación previa y ventana temporal, y todo queda registrado en CloudTrail en una cuenta de auditoría a la que los administradores de las cuentas no pueden acceder. Reviso trimestralmente los permisos realmente utilizados con el analizador de accesos y recorto lo que lleva noventa días sin usarse.

Con un control preventivo y no con una norma escrita en un documento. En AWS aplico una Service Control Policy a nivel de organización que deniega cualquier acción cuya región solicitada no esté en la lista autorizada, con la salvedad de los servicios globales imprescindibles, como IAM, Route 53 o CloudFront, que hay que excluir de forma explícita para no romper la cuenta; en Azure el equivalente es una política de ubicaciones permitidas asignada en el grupo de administración raíz. Después reviso los servicios que por diseño procesan o almacenan fuera de la región, caso de algunas funcionalidades de inteligencia artificial o de ciertos registros de servicios globales, y los sustituyo o los desactivo. Controlo también las copias de seguridad y la replicación entre regiones, que es la vía por la que los datos se escapan sin que nadie lo note, y los buckets con replicación heredada de otra época. Añado cifrado con claves gestionadas por el cliente y residentes en la región, con lo que aunque un objeto acabara fuera seguiría siendo ilegible sin acceso a la clave. Y verifico de forma continua con reglas de configuración y un cuadro de conformidad, porque en una auditoría hay que demostrarlo con evidencia, no afirmarlo.

Antes de nombrar ningún servicio pregunto cinco cosas. Primera, el RTO y el RPO que negocio está dispuesto a pagar, porque de ahí sale casi todo lo demás y suele ser la primera vez que alguien se lo plantea. Segunda, el patrón de acceso: proporción de lectura y escritura, tamaño del conjunto de datos, si hay consultas analíticas mezcladas con la operativa y si el crecimiento es lineal o estacional. Tercera, el modelo de datos y las restricciones reales, es decir, si hace falta consistencia fuerte y transacciones o si la aplicación tolera consistencia eventual, porque eso decide entre relacional y no relacional mucho más que la moda. Cuarta, las obligaciones normativas: residencia, cifrado con clave propia, retención de copias y capacidad de recuperación a un punto en el tiempo. Y quinta, el presupuesto y la ventana de mantenimiento aceptable. Con eso, para una carga transaccional típica propongo Aurora con réplica en otra zona de disponibilidad y conmutación automática, réplicas de lectura para descargar consultas y recuperación a un punto en el tiempo; si el requisito es multirregión, valoro base de datos global asumiendo el sobrecoste y la latencia de replicación. Y aviso siempre de lo mismo: la alta disponibilidad gestionada no protege contra un borrado accidental, así que hacen falta copias independientes.

Significa que el proveedor responde de la seguridad de la nube (instalaciones, hardware, red física, hipervisor y el plano de control de los servicios gestionados) y el cliente responde de la seguridad en la nube (configuración, identidades y permisos, cifrado y gestión de claves, red virtual, parcheado de lo que ejecuta y, sobre todo, sus propios datos). La frontera se desplaza según el tipo de servicio: en una instancia de cómputo el sistema operativo es suyo, mientras que en una función sin servidor no lo es, aunque el permiso y el dato sigan siéndolo. En la práctica falla casi siempre en los mismos puntos: creer que el proveedor hace copias de seguridad de sus datos cuando lo que garantiza es la durabilidad del almacenamiento frente a fallos de hardware, no frente a un borrado suyo; asumir que la replicación equivale a copia; dejar buckets o cuentas de almacenamiento con acceso público; conservar claves de larga duración en repositorios; y no parchear las imágenes base de los contenedores. En un proyecto sujeto al Esquema Nacional de Seguridad esta frontera hay que documentarla de forma explícita en la declaración de aplicabilidad, indicando qué medidas hereda del proveedor certificado y cuáles implanta usted.

Confirmo primero el alcance real en el panel y en la página de estado del proveedor, para saber si es un problema del proveedor o mío, porque la respuesta es distinta. Abro el canal de incidencia y aviso, de forma que no haya dos personas actuando a ciegas sobre el mismo sistema, y designo quién comunica a negocio mientras yo trabajo. Si el diseño es correcto, la conmutación debería ser automática, así que mi primera comprobación es por qué no lo ha sido: reviso si hay recursos anclados a esa zona (una base de datos sin réplica en espera, un grupo de autoescalado con capacidad fija en una sola zona, un punto de montaje de almacenamiento zonal), y fuerzo la conmutación de lo que se pueda conmutar y el escalado en las zonas sanas. No inicio una conmutación de región salvo que el impacto se prolongue por encima del RTO comprometido, porque volver atrás siempre cuesta más de lo previsto y esa decisión no debe tomarse en caliente y en solitario. Durante todo el proceso voy anotando la línea temporal. Y al día siguiente el resultado no es solo un informe: es una lista concreta de recursos anclados a una zona que hay que corregir, y una prueba de inyección de fallos que lo verifique.

Acepto el objetivo, pero pido acordar antes qué no se toca, porque un recorte del 20 % mal hecho se paga con una caída que cuesta más que el ahorro. Presento el desglose por unidad de negocio y por servicio y ordeno las medidas en tres bloques según el riesgo. Riesgo cero y efecto inmediato: eliminar recursos huérfanos, apagar preproducción fuera del horario laboral, ciclos de vida en el almacenamiento, sustituir NAT por endpoints, actualizar tipos de volumen y de instancia. Riesgo bajo con validación técnica: dimensionar a la baja con datos de uso reales, consolidar clústeres infrautilizados y usar instancias interrumpibles en cargas tolerantes. Y compromisos de tarifa, que reducen la factura sin tocar la arquitectura pero atan uno o tres años, por lo que solo los firmo sobre la base estable, nunca sobre el pico. Cada medida va con euros estimados, con la fecha en la que se hace efectiva y con un responsable, y lo llevo a un comité quincenal. Si con eso no se llega al 20 %, digo con claridad qué falta: normalmente hay una decisión de negocio detrás, como retirar un entorno o aceptar un nivel de servicio menor en una aplicación secundaria, y esa decisión no la puedo tomar yo solo.

Primero compruebo el impacto y si hay riesgo de seguridad o de coste inmediato, y si lo hay lo trato como una incidencia, no como un asunto de proceso. Si no lo hay, hablo con esa persona antes que con nadie más, y con una pregunta y no con un reproche: casi siempre resulta que el módulo no cubría su caso, que la aprobación tardaba tres días o que estaba resolviendo una urgencia de madrugada. A partir de ahí, importo los recursos al estado de Terraform o los recreo desde código en una ventana acordada, para que el entorno vuelva a ser reproducible. Y llevo el motivo al equipo: si el camino aprobado no cubre un caso legítimo, lo cubrimos; si el problema es el plazo de aprobación, lo acortamos. Cuando la situación se repite, lo hago visible sin señalar a personas, con una revisión semanal de desviaciones que llegó a destapar 87 recursos creados a mano y 2.300 € al mes de gasto huérfano. Escalo al responsable solo si el patrón continúa después de haber resuelto la causa, porque entonces ya no es un problema de herramientas.

Empiezo diciendo con claridad que hoy no se cumple, porque una copia diaria implica un RPO de hasta 24 horas, y el peor error sería firmar el compromiso y descubrirlo el día del incidente. Después traduzco los dos números a arquitectura: el RPO de 15 minutos exige replicación continua o casi continua de la capa de datos, con base de datos global o envío frecuente de registros de transacciones y replicación entre regiones del almacenamiento de objetos; el RTO de 4 horas admite una estrategia de luz piloto, con el entorno definido en código y los datos ya presentes en la segunda región, sin necesidad de mantener todo encendido. Presento dos opciones con su coste mensual y su riesgo: la de luz piloto, que cumple con holgura si la restauración está ensayada, y la de warm standby, más cara pero con margen si la conmutación se complica. Incluyo en la propuesta el coste de lo que casi nadie presupuesta, que son los simulacros semestrales y el tiempo de las personas, porque un plan sin probar no cumple ningún pliego. Y dejo por escrito los supuestos: qué sistemas quedan dentro del alcance, cuáles no, y qué depende de terceros que no controlamos.

Trato de convertir la discusión de opiniones en una de datos, porque discutir preferencias con un superior no lleva a ningún sitio. Le pido el requisito de negocio que hay detrás: cuál es el RTO comprometido, qué cuesta una hora de indisponibilidad y si existe una obligación regulatoria o contractual, porque en el sector financiero a veces la hay y entonces la conversación se acaba ahí. Después presento la comparación con números: coste mensual de cada opción, incluida la transferencia entre regiones, y el coste oculto, que es la consistencia de datos, la complejidad operativa y el hecho de que un despliegue erróneo se propaga igual a las dos regiones, de modo que activo-activo protege frente al fallo de infraestructura pero no frente al fallo lógico, que es el más frecuente. Propongo un camino intermedio: warm standby con simulacros trimestrales, que en nuestro caso cumplía el RTO de cuatro horas por menos de la mitad de coste, con la puerta abierta a evolucionar si el negocio cambia. Y si tras esa conversación la decisión sigue siendo activo-activo, la ejecuto lo mejor que sé y dejo mi análisis documentado, sin convertirlo en un conflicto personal.