AWS Preguntas de entrevista

Lo que cubren las entrevistas de AWS

Ejemplos de preguntas de entrevista sobre AWS

• Explica la diferencia entre un Security Group y una Network ACL. ¿Cuándo usarías cada uno?
  Lo que cubre una buena respuesta

  • Security Group: stateful (permite tráfico de respuesta automáticamente), evalúa todas las reglas, solo permite reglas, a nivel de instancia/eni.
  • NACL: stateless (requiere reglas explícitas de entrada y salida), evalúa reglas en orden, permite deny, a nivel de subred.
  • Usar Security Group para control granular por instancia (ej. solo acceso SSH desde IPs específicas).
  • Usar NACL para capa adicional de defensa a nivel de subred (ej. bloquear un país completo).

  Ver respuesta de ejemplo

  Un Security Group actúa como un firewall virtual a nivel de instancia, es stateful, lo que significa que el tráfico de respuesta se permite automáticamente sin necesidad de reglas explícitas de salida. Solo admite reglas de allow. En cambio, una Network ACL (NACL) es stateless, opera a nivel de subred y requiere reglas separadas para tráfico de entrada y salida; además, soporta reglas de deny y se evalúan en orden numérico. Por lo general, se usan Security Groups para la mayoría de los casos de seguridad básica, ya que simplifican la administración. Las NACLs son útiles como capa adicional de defensa en entornos con requisitos de cumplimiento estrictos o para bloquear rangos de IP específicos a nivel de subred. Sin embargo, su naturaleza stateless puede complicar la gestión del tráfico de retorno, por lo que se recomienda combinarlas con Security Groups para un enfoque de defensa en profundidad.

• Diseña una aplicación web altamente disponible y tolerante a fallos en AWS. Incluye componentes de cómputo, almacenamiento y redes.
  Lo que cubre una buena respuesta

  • Cómputo: Auto Scaling Group con instancias EC2 en múltiples AZs, balanceador de carga (ALB).
  • Almacenamiento: RDS Multi-AZ para base de datos, S3 para assets estáticos, EFS para archivos compartidos.
  • Redes: VPC con subnets públicas y privadas, NAT Gateway para salida a internet, Route53 con failover.

  Ver respuesta de ejemplo

  Para una aplicación web altamente disponible y tolerante a fallos, se debe distribuir la infraestructura en múltiples Zonas de Disponibilidad (AZ). En cómputo, se utiliza un Application Load Balancer (ALB) que distribuye el tráfico entre instancias EC2 lanzadas en un Auto Scaling Group configurado con mínimo dos instancias en diferentes AZs. Para el almacenamiento de la base de datos, se emplea RDS con Multi-AZ (sincrónico) para failover automático, añadiendo réplicas de lectura opcionales para escalar consultas. Los archivos estáticos y medios se almacenan en S3, y para archivos compartidos entre instancias (ej. sesiones) se usa EFS, también multi-AZ. En la capa de red, se diseña una VPC con subnets públicas (ALB, NAT Gateway) y privadas (EC2, RDS). Los NAT Gateways se despliegan en cada AZ para redundancia. Route53 con políticas de enrutamiento de failover o ponderado garantiza la conmutación por error a nivel de DNS. Se debe monitorear la salud de la aplicación con CloudWatch y configurar alarmas. La tolerancia a fallos se logra eliminando puntos únicos de falla: cada componente tiene redundancia y capacidad de escalar.

• ¿Cómo migrarías una aplicación monolítica local a AWS con un tiempo de inactividad mínimo? Discute la estrategia y las herramientas.
  Lo que cubre una buena respuesta

  • Usar AWS Application Migration Service (MGN) para replicación continua de servidores.
  • Base de datos: AWS DMS para migración en vivo con replicación continua hacia RDS.
  • Estrategia: lift-and-shift (rehost) con pruebas y corte gradual usando Route53 weighted routing.

  Ver respuesta de ejemplo

  Para migrar una aplicación monolítica local a AWS con mínimo tiempo de inactividad, la estrategia más común es el rehosting (lift-and-shift) utilizando AWS Application Migration Service (MGN). MGN replica continuamente los servidores locales a AWS, permitiendo un corte rápido. La base de datos se migra con AWS Database Migration Service (DMS) en modo de replicación continua hacia una instancia RDS, minimizando la ventana de migración. Se recomienda configurar un entorno de staging en AWS, realizar pruebas de integración y rendimiento, y luego usar Route53 con políticas de enrutamiento ponderado para dirigir gradualmente el tráfico hacia AWS. Para reducir el downtime, se programa la ventana de corte durante horas de baja actividad, se detiene la aplicación local, se sincronizan los cambios finales y se conmutan las DNS. Como alternativa, se puede usar CloudEndure (ahora parte de MGN) para replicación a nivel de bloque. Es crucial validar los RTO/RPO deseados y tener un plan de reversión. Herramientas complementarias: AWS Server Migration Service (SMS) para servidores VMware, y AWS CloudFormation para infraestructura como código.

• Escribe una función Lambda en Python que procese notificaciones de eventos de S3 (por ejemplo, redimensionamiento de imágenes). Muestra el handler y la política de IAM.
  Lo que cubre una buena respuesta

  • Función Lambda en Python que se activa por evento de S3 (PutObject).
  • Usa Pillow (PIL) para redimensionar imagen y subir de vuelta a otro bucket o prefijo.
  • Incluir política de IAM con permisos s3:GetObject y s3:PutObject en los buckets relevantes.

  Ver respuesta de ejemplo

  La función Lambda se escribe en Python y se configura con un trigger de S3. El código lee el evento, extrae el nombre del bucket y la clave del objeto, descarga la imagen, la redimensiona a un tamaño predefinido (ej. 200x200) usando Pillow, y la sube a un bucket de destino. Se requiere la librería Pillow empaquetada como capa de Lambda o incluida en el deployment package. La política de IAM debe permitir s3:GetObject en el bucket de origen y s3:PutObject en el bucket de destino. Además, se concede permiso a S3 para invocar la función. El código maneja errores y registra logs en CloudWatch. La complejidad temporal es O(n*m) donde n,m son dimensiones de la imagen; espacial O(n*m) por la imagen en memoria.

  import boto3
  import os
  from PIL import Image
  import io
  
  def lambda_handler(event, context):
      # Obtener bucket y clave del evento S3
      bucket = event['Records'][0]['s3']['bucket']['name']
      key = event['Records'][0]['s3']['object']['key']
      
      # Configurar cliente S3
      s3 = boto3.client('s3')
      
      # Descargar la imagen original
      response = s3.get_object(Bucket=bucket, Key=key)
      image_content = response['Body'].read()
      
      # Abrir imagen con Pillow
      try:
          img = Image.open(io.BytesIO(image_content))
          # Redimensionar manteniendo relación de aspecto, tamaño máximo 200px
          img.thumbnail((200, 200))
          
          # Guardar en buffer
          buffer = io.BytesIO()
          img.save(buffer, format=img.format if img.format else 'JPEG')
          buffer.seek(0)
          
          # Subir imagen redimensionada a bucket destino (ej: 'resized-images')
          dest_bucket = os.environ.get('DEST_BUCKET', 'resized-images')
          # Mantener la misma clave, o prefijo
          s3.put_object(Bucket=dest_bucket, Key=key, Body=buffer)
      except Exception as e:
          print(f"Error procesando imagen {key}: {e}")
          raise e
  ```

• Compara RDS, DynamoDB y ElastiCache. Para una tabla de clasificación en tiempo real, ¿cuál elegirías y por qué?
  Lo que cubre una buena respuesta

  • RDS: relacional, ACID, esquema fijo, costes medios, idóneo para transacciones complejas.
  • DynamoDB: NoSQL, alta escalabilidad, baja latencia, sin esquema, buen rendimiento con cargas predecibles.
  • ElastiCache: en memoria, latencia sub-milisegundo, ideal para caché y datos volátiles como rankings.

  Ver respuesta de ejemplo

  Para una tabla de clasificación en tiempo real, ElastiCache con Redis es la mejor opción debido a que soporta estructuras de datos como sorted sets (conjuntos ordenados) con operaciones O(log N) para inserciones y consultas de ranking. DynamoDB también es viable con transacciones y secuencias, pero la latencia es mayor al ser persistente en disco, y las lecturas de ranking requieren consultas costosas. RDS no es adecuado por su latencia y la necesidad de escribir consultas SQL complejas para obtener rankings. ElastiCache ofrece sub-milisegundos de latencia, ideal para actualizaciones frecuentes. Sin embargo, si se necesita persistencia duradera, DynamoDB combinada con ElastiCache como capa de caché es una alternativa. Para este escenario, la simplicidad de Redis sorted sets y su rendimiento superior lo convierten en la elección clara.

• Describe un escenario donde usarías un VPC endpoint en lugar de un NAT Gateway. ¿En qué se diferencian en costo y rendimiento?
  Lo que cubre una buena respuesta

  • VPC Endpoint: permite acceso privado a servicios AWS (S3, DynamoDB) sin salir a internet.
  • NAT Gateway: proporciona salida a internet desde subnets privadas, pero requiere ruteo a través de internet.
  • VPC Endpoint no tiene costo de transferencia de datos por GB (Gateway), NAT Gateway sí cobra por hora y por datos.

  Ver respuesta de ejemplo

  Un VPC Endpoint (Gateway endpoint para S3 y DynamoDB) permite que los recursos en subnets privadas accedan a estos servicios de forma privada, sin necesidad de pasar por internet. No tiene costo por hora y el costo de procesamiento de datos es menor o nulo (dependiendo del tipo). Un NAT Gateway, en cambio, se usa para que instancias en subnets privadas accedan a internet (ej. descargar parches), con un costo por hora y por datos procesados. Se debe elegir VPC Endpoint cuando solo se necesita acceder a servicios de AWS como S3 o DynamoDB, ya que ofrece mejor rendimiento (menor latencia) y menor costo. NAT Gateway es necesario cuando se requiere acceso a internet para fines no cubiertos por endpoints (ej. actualizaciones de sistema, APIs externas). Desde el punto de vista del rendimiento, los VPC Endpoints (Gateway) no añaden latencia significativa, mientras que NAT Gateway introduce una ligera latencia adicional y puede ser un cuello de botella si no se dimensiona correctamente.

• ¿Cómo logra S3 una consistencia fuerte para las operaciones PUT y DELETE? Explica el modelo subyacente.
  Lo que cubre una buena respuesta

  • Desde diciembre 2020, S3 ofrece consistencia fuerte para todas las operaciones (PUT, DELETE, etc.).
  • Antes era eventual para escrituras de objetos nuevos si se leía inmediatamente.
  • Subyacente: replicación síncrona en tres AZs y confirmación antes de responder al cliente.

  Ver respuesta de ejemplo

  S3 logró consistencia fuerte mediante una revisión de su modelo de replicación. Anteriormente, S3 ofrecía consistencia eventual para ciertos escenarios (ej. escrituras de nuevos objetos). Desde diciembre de 2020, todas las operaciones PUT, DELETE, POST y GET ofrecen consistencia fuerte de lectura-después-de-escritura. Esto significa que después de completar un PUT o DELETE, cualquier GET devuelve inmediatamente los datos más recientes. El modelo subyacente utiliza replicación síncrona entre múltiples Zonas de Disponibilidad dentro de la región (para almacenamiento redundante) y un sistema de consenso distribuido que garantiza que la operación se confirma solo cuando todos los nodos relevantes han persistido los datos. Este cambio implicó un aumento en la latencia de escritura, pero proporciona la garantía que muchas aplicaciones requieren. La consistencia fuerte simplifica el desarrollo de aplicaciones al eliminar la necesidad de lidiar con datos obsoletos.

• Escribe un fragmento de plantilla de CloudFormation que cree una instancia EC2 con un security group personalizado y etiquetas.
  Lo que cubre una buena respuesta

  • Recurso EC2: tipo t2.micro, AMI Amazon Linux 2, asociar a Security Group.
  • Security Group: permitir SSH (22) y HTTP (80) desde 0.0.0.0/0.
  • Tags: agregar etiquetas obligatorias (Name, Environment, etc.) usando el bloque Tags.

  Ver respuesta de ejemplo

  En CloudFormation, se definen dos recursos: AWS::EC2::Instance y AWS::EC2::SecurityGroup. El Security Group se crea primero para asignarlo a la instancia. Se especifica el grupo en las propiedades del EC2 mediante SecurityGroupIds. Las etiquetas se asignan tanto a la instancia como al grupo. Es recomendable parametrizar valores como el AMI ID o el tipo de instancia para flexibilidad. Se debe tener cuidado con las dependencias para evitar errores de referencias circulares. La plantilla se puede escribir en YAML o JSON; aquí se usa YAML por legibilidad.

  AWSTemplateFormatVersion: '2010-09-09'
  Description: Plantilla para crear una instancia EC2 con Security Group y etiquetas
  Resources:
    MySecurityGroup:
      Type: AWS::EC2::SecurityGroup
      Properties:
        GroupDescription: Security group para la instancia EC2
        VpcId: !Ref VPCId  # Se debe parametrizar o usar Default VPC
        SecurityGroupIngress:
          - IpProtocol: tcp
            FromPort: 22
            ToPort: 22
            CidrIp: 0.0.0.0/0
          - IpProtocol: tcp
            FromPort: 80
            ToPort: 80
            CidrIp: 0.0.0.0/0
        Tags:
          - Key: Name
            Value: MiSecurityGroup
    MyEC2Instance:
      Type: AWS::EC2::Instance
      Properties:
        ImageId: ami-0abcdef1234567890  # Reemplazar con AMI ID válido
        InstanceType: t2.micro
        SecurityGroupIds:
          - !Ref MySecurityGroup
        Tags:
          - Key: Name
            Value: MiInstanciaEC2
          - Key: Environment
            Value: Desarrollo
  ```

Cómo prepararse

• Practica de forma práctica: Despliega una pequeña aplicación usando EC2, S3 y RDS. Rómpela y depura usando CloudWatch Logs y VPC Flow Logs.
• Domina los pilares del AWS Well-Architected Framework (costo, rendimiento, confiabilidad, seguridad, excelencia operativa) y prepárate para discutir trade-offs.
• Comprende los patrones de diseño comunes: multi-AZ, réplicas de lectura, auto-scaling y despliegues blue/green. Usa el nivel gratuito de AWS para experimentar.
• Sé fluido en al menos una herramienta de Infraestructura como Código (CloudFormation, CDK o Terraform) y un lenguaje de scripting (Python, Node.js).
• Revisa las sesiones de AWS re:Invent y la documentación oficial de los servicios en los que afirmas tener experiencia. Los entrevistadores a menudo preguntan sobre 'últimas características'.

Preguntas frecuentes