How long are immutable records of past Oracle Database@AWS API calls retained by default in AWS CloudTrail Event History?
A. 90 days
B. 30 days
C. 60 days
D. 1 year
A
What must be the state of Oracle Database@AWS resources for metrics to be monitored by Amazon CloudWatch and events by Amazon EventBridge?
A. Terminated
B. Available
C. Deleting
D. Stopped
B
Which AWS service is used to collect and process raw data into readable, near real-time metrics for Oracle Database@AWS resources?
A. Amazon SNS
B. Amazon CloudWatch
C. AWS CloudTrail
D. Amazon EventBridge
B
✔️ Por qué la B (Amazon CloudWatch) es la correcta
La pregunta describe la definición exacta de Amazon CloudWatch.
“recopilar y procesar datos brutos”: Esta es la función principal de CloudWatch. Recibe puntos de datos (métricas) de casi todos los servicios de AWS, incluido Oracle Database@AWS.
“en métricas legibles y casi en tiempo real”: CloudWatch toma esos datos brutos (por ejemplo, cpu_utilization: 80% a las 10:01:00) y los procesa en gráficos, paneles (dashboards) y estadísticas que puedes consultar en tiempo real.
En resumen, cuando piensas en métricas, rendimiento y monitoreo en AWS, la respuesta casi siempre es CloudWatch. Es el servicio central de observabilidad.
❌ Por qué las otras son incorrectas
A. Amazon SNS (Simple Notification Service): Es un servicio de notificación. Su trabajo es enviar mensajes (como emails, SMS o notificaciones push) a personas o servicios. CloudWatch usa SNS para enviar alertas (por ejemplo, “¡Alerta! La CPU superó el 90%”), pero SNS no es quien recopila o procesa las métricas.
C. AWS CloudTrail: Es un servicio de auditoría y gobernanza. CloudTrail responde a la pregunta: “¿Quién hizo qué y cuándo?”. Registra cada llamada a la API en tu cuenta (ej. “El usuario ‘admin’ creó una base de datos a las 10:05”). No rastrea métricas de rendimiento como el uso de CPU o el espacio en disco.
D. Amazon EventBridge: Es un bus de eventos sin servidor. Su trabajo es conectar aplicaciones y enrutar eventos (señales de que “algo pasó”). Por ejemplo, puede tomar un evento de “base de datos creada” y enviarlo a una función Lambda para que realice una acción. No está diseñado para recopilar y almacenar series temporales de métricas de rendimiento.
What is the process to access AWS CloudTrail records that are older than 90 days?
A. You can only view them via a special AWS support request.
B. You must create a CloudTrail Lake event data store.
C. They are automatically archived and cannot be accessed.
D. They are stored in Amazon S3 by default and can be retrieved.
B
Which of the following is NOT a metric monitored for an Exadata VM Cluster in Amazon CloudWatch?
A. Block Changes
B. OCPU Allocated
C. ASM Disk Group Utilization
D. CPU Utilization %
A
✔️ Por qué A es la respuesta (NO es monitoreada)
A) Block Changes
Qué es: Esta es una métrica interna de la base de datos Oracle. Mide la actividad o la carga de trabajo (cuántos bloques de datos se están modificando).
Por qué no: CloudWatch monitorea el VM Cluster (la máquina virtual), no la carga de trabajo específica que se ejecuta dentro de la base de datos. “Block Changes” es una métrica que encontrarías en Oracle Enterprise Manager o consultando las vistas V$ de la base de datos, pero no es una métrica de infraestructura que CloudWatch exponga de forma nativa para el recurso del VM Cluster.
❌ Por qué las otras opciones SÍ son monitoreadas
B) OCPU Allocated (OCPU Asignadas)
Qué es: Esta es una métrica de configuración y capacidad.
Por qué sí: CloudWatch sí rastrea esto. Es fundamental para la facturación, la planificación de la capacidad y la comprensión de los límites del clúster saber cuántas OCPU están provisionadas.
C) ASM Disk Group Utilization (Utilización del Grupo de Discos ASM)
Qué es: Esta es una métrica de infraestructura de almacenamiento.
Por qué sí: Esta es una métrica de salud crítica. CloudWatch sí monitorea el porcentaje de espacio utilizado en los grupos de discos ASM (como DATA y RECO). Si el disco se llena, la base de datos deja de funcionar. Por lo tanto, es una métrica de infraestructura esencial.
D) CPU Utilization % (Porcentaje de Utilización de CPU)
Qué es: Esta es la métrica de infraestructura de cómputo más fundamental.
Por qué sí: CloudWatch siempre monitorea la utilización de la CPU de cualquier recurso de cómputo (como un VM Cluster o una instancia EC2). Es la principal forma de saber si el clúster tiene suficiente potencia de procesamiento o si está sobrecargado.
What is the purpose of the aws.partner/odb/ event bus created in a customer’s AWS account?
A. To collect performance metrics from Exadata VM Clusters
B. To send events from AWS services to OCI
C. To log all Oracle Database@AWS API calls
D. To receive events from OCI about Oracle Database@AWS resources
D
✅ La respuesta correcta: D
D. Para recibir eventos de OCI sobre los recursos de Oracle Database@AWS
Esta es la respuesta correcta porque define exactamente la arquitectura de “Oracle Database@AWS”.
¿Qué es “Oracle Database@AWS”? Es un servicio donde el hardware de base de datos de Oracle (Exadata) se coloca físicamente dentro de un centro de datos de AWS, pero es gestionado por Oracle (OCI - Oracle Cloud Infrastructure).
¿Qué es un “Partner Event Bus”? En Amazon EventBridge (el servicio de AWS para eventos), un bus de eventos con el prefijo aws.partner/ está diseñado específicamente para que un socio (Partner) de AWS pueda enviar eventos hacia la cuenta del cliente.
Uniendo los conceptos: Dado que OCI (el socio) gestiona el hardware y el software de la base de datos, necesita una forma de notificar a tu cuenta de AWS sobre eventos importantes que ocurren en esos recursos (por ejemplo: “la base de datos se ha iniciado”, “se está aplicando un parche”, “hay un fallo de hardware”, etc.).
El aws.partner/odb/ (donde ‘odb’ probablemente signifique Oracle Database) es el canal oficial por el cual OCI (el socio) envía esos eventos, y tu cuenta de AWS los recibe.
❌ Por qué las otras son incorrectas
A. Para recopilar métricas de rendimiento de los Exadata VM Clusters
Incorrecto. El servicio de AWS para recopilar métricas de rendimiento (como uso de CPU, I/O de disco, etc.) es Amazon CloudWatch Metrics. Amazon EventBridge (donde viven los “event bus”) se usa para eventos (cambios de estado, como “iniciado” o “detenido”), no para flujos continuos de datos de métricas.
B. Para enviar eventos desde servicios de AWS a OCI
Incorrecto. Esto describe la dirección opuesta. Como se explicó, un partner event bus (aws.partner/) está diseñado para recibir eventos del socio (OCI), no para enviar eventos al socio.
C. Para registrar todas las llamadas API de Oracle Database@AWS
Incorrecto. El servicio de AWS que registra las llamadas API (quién hizo qué, cuándo y desde dónde) es AWS CloudTrail. Si bien un evento de CloudTrail podría enviarse a EventBridge, el propósito principal del bus aws.partner/odb/ no es registrar llamadas API, sino recibir notificaciones de estado desde OCI.
¿Cuál es el período de retención por defecto para las métricas recopiladas por Amazon CloudWatch en Oracle Database@AWS?
A) 30 días
B) 90 días
C) 15 meses
D) 24 meses
C
✔️ Por qué la C (15 meses) es la correcta
La clave es entender que Amazon CloudWatch no guarda todas las métricas con el mismo nivel de detalle (granularidad) para siempre. Automáticamente “comprime” los datos a medida que envejecen para ahorrar espacio.
El período de retención por defecto de CloudWatch funciona así:
Métricas con granularidad de < 1 minuto (alta resolución): Se guardan durante 3 horas.
Métricas con granularidad de 1 minuto: Se guardan durante 15 días.
Métricas con granularidad de 5 minutos: Se guardan durante 63 días (aprox. 2 meses).
Métricas con granularidad de 1 hora: Se guardan durante 455 días (aprox. 15 meses).
Cuando la pregunta habla del “período de retención por defecto”, casi siempre se refiere al tiempo máximo que CloudWatch retiene los datos de forma nativa. Pasados los 63 días, CloudWatch consolida las métricas en puntos de datos de 1 hora, y esos puntos se pueden consultar hasta 15 meses atrás.
El hecho de que sea “Oracle Database@AWS” no cambia esta regla; este servicio simplemente envía sus métricas a CloudWatch, y CloudWatch las gestiona según su política estándar.
¿En qué espacio de nombres de AWS/ODB se reportan las métricas específicas de los recursos de Oracle Database@AWS?
A) AWS/Database
B) AWS/ODB
C) AWS/Oracle
D) AWS/CloudWatch
B
¿Cuál es el requisito previo para que CloudWatch pueda recopilar métricas de un recurso de base de datos en Oracle Database@AWS?
A) El recurso debe estar en estado de replicación
B) El recurso debe estar en estado disponible
C) El recurso debe tener al menos 8 vCPU
D) El recurso debe estar asociado a una subred pública
B
¿Cuáles son los tres tipos principales de recursos que pueden ser monitoreados con Amazon CloudWatch en Oracle Database@AWS? (Selecciona tres)
A) Exadata VM Cluster
B) Container Database
C) Autonomous Database
D) Instance de EC2 dedicadas
A, B y C
✔️ Por qué A, B y C son correctas
Para entender esto, primero hay que saber qué es Oracle Database@AWS. Es un servicio híbrido que coloca hardware de Oracle Exadata (un sistema de hardware y software diseñado específicamente para bases de datos Oracle) en tu propio centro de datos, pero es completamente gestionado por AWS, como si fuera un servicio más de la nube.
Este servicio te permite desplegar dos “sabores” de bases de datos Oracle en ese hardware. Las métricas de todos los componentes clave se envían a Amazon CloudWatch.
A) Exadata VM Cluster: Esta es la capa de infraestructura fundamental. Es el clúster de máquinas virtuales que se ejecuta sobre el hardware físico de Exadata. Es el primer recurso que creas y necesitas monitorear su estado general (CPU, memoria, almacenamiento del clúster). Por lo tanto, es un recurso monitoreado.
B) Container Database (CDB): Este es uno de los dos tipos de bases de datos que puedes desplegar. Corresponde al servicio “Amazon RDS for Oracle” ejecutándose en tu hardware Exadata@AWS. Un CDB (Base de Datos Contenedora) aloja otras bases de datos (PDBs). CloudWatch monitorea el estado del CDB (espacio, sesiones, etc.).
C) Autonomous Database: Este es el segundo tipo de base de datos que puedes desplegar en la plataforma Exadata@AWS. Es la oferta de base de datos “autónoma” de Oracle (que se auto-parchea, auto-gestiona, etc.). Al igual que el CDB, este es un recurso de base de datos principal cuyo rendimiento y estado se monitorean a través de CloudWatch.
En resumen, monitoreas la infraestructura (el VM Cluster) y los dos tipos de servicios de base de datos que puedes ejecutar sobre ella (CDB para RDS o Autonomous Database).
❌ Por qué la D es incorrecta
D) Instance de EC2 dedicadas: Esta es la opción incorrecta porque “Oracle Database@AWS” no se ejecuta en instancias EC2. El corazón de este servicio es el uso de hardware especializado Oracle Exadata que se instala en las instalaciones del cliente. Las instancias EC2 son el hardware virtualizado estándar dentro de la nube pública de AWS. Confundir esto es un error conceptual clave sobre para qué sirve este servicio híbrido.
Según el modelo de monitoreo de Oracle Database@AWS, ¿qué métrica se considera crítica para evaluar la carga de trabajo en una Container Database?
A) Única y exclusivamente CPU Utilization
B) Solo Block Changes y Parse Count
C) CPU Utilization, Block Changes, Parse Count, Execute Count y User Calls
D) Solo Swap Space Utilization
C
En una arquitectura con Exadata VM Cluster, ¿qué métrica específica permite identificar posibles problemas de memoria insuficiente en el sistema operativo?
A) CPU Utilization
B) SWAP Space Utilization
C) Memory Utilization
D) Load Average
B
✅ Por qué la Opción B es la Correcta
B) SWAP Space Utilization (Uso de espacio SWAP)
¿Qué es SWAP? El espacio de SWAP (o memoria virtual) es un área en el disco duro (o SSD) que el sistema operativo utiliza como si fuera memoria RAM.
¿Cuándo se usa? El sistema operativo (Linux, en el caso de Exadata) solo utiliza el espacio SWAP cuando se ha quedado sin memoria RAM física para las aplicaciones y procesos que la están exigiendo activamente.
¿Por qué es el indicador clave? El SWAP es órdenes de magnitud más lento que la RAM. En un sistema de alto rendimiento como Exadata, el uso de SWAP (un proceso llamado swapping o paging) es catastrófico para el rendimiento de la base de datos. Por lo tanto, si la métrica “SWAP Space Utilization” es alta (o incluso si muestra cualquier actividad), es la señal específica e inequívoca de que el sistema operativo tiene memoria insuficiente y está intentando compensarlo de la peor manera posible.
❌ Por qué las Otras Opciones Son Incorrectas
A) CPU Utilization (Uso de CPU): Esto mide qué tan ocupado está el procesador. Aunque un uso de CPU muy alto puede a veces ser un síntoma de falta de memoria (un fenómeno llamado thrashing, donde el sistema gasta toda su CPU solo en mover memoria de RAM a SWAP), no es el indicador directo. Se puede tener un 100% de CPU con mucha memoria libre (ej. un cálculo matemático intenso).
C) Memory Utilization (Uso de Memoria): Esta es la respuesta “trampa”. En sistemas operativos modernos como Linux, un uso de memoria alto (ej. 95-99%) es normal y saludable. El sistema operativo utiliza toda la RAM libre para caching de disco (caché del sistema de archivos) para acelerar las operaciones. Un “Uso de Memoria” alto no significa que haya un problema; solo significa que la memoria se está utilizando. El problema real (que la Opción B detecta) es cuando no hay suficiente memoria ni siquiera para los procesos activos y el OS se ve forzado a usar el disco (SWAP).
D) Load Average (Promedio de Carga): Esta métrica indica cuántos procesos están ejecutándose o esperando en la cola para usar la CPU. Al igual que la CPU, un “Load Average” alto puede ser un síntoma de swapping (porque los procesos se quedan “atascados” esperando que sus datos vuelvan del SWAP al RAM), pero no es la métrica específica. Se puede tener un “Load Average” alto por una carga de trabajo legítima y sin problemas de memoria.
¿Cuál es la función principal de Amazon EventBridge en el contexto de Oracle Database@AWS?
A) Recopilar y procesar métricas de rendimiento en tiempo real
B) Monitorear eventos de ciclo de vida de recursos y entregar estos eventos a objetivos específicos
C) Almacenar registros de auditoría de todas las operaciones de API
D) Encriptar los datos en tránsito entre Oracle Database@AWS y AWS
B
¿Qué componente de Amazon EventBridge actúa como enrutador que recibe eventos, los transforma opcionalmente y los entrega a los objetivos?
A) Event Rule
B) Event Pattern
C) Event Bus
D) Event Target
C
Cuando se generan eventos en AWS para recursos de Oracle Database@AWS, ¿a cuál event bus se entregan por defecto?
A) Al event bus creado con prefijo aws.partner/odb
B) Al event bus por defecto de la cuenta de AWS del cliente
C) A un event bus específico creado exclusivamente para Oracle Database
D) A todos los event buses disponibles en la región
B
Por qué es correcta:
En Amazon EventBridge, todos los servicios de AWS que generan eventos (como Oracle Database@AWS, EC2, S3, RDS, etc.) envían sus eventos al “event bus por defecto” (default event bus) de la cuenta del cliente.
Ese default event bus actúa como el canal central donde se reciben los eventos de los servicios de AWS dentro de tu cuenta.
Desde ahí, puedes crear reglas para filtrar, transformar y redirigir los eventos a otros destinos (por ejemplo, Lambda, SNS, SQS, Step Functions…).
Solo si tú lo configuras manualmente, los eventos pueden ir a un custom event bus o a un partner event bus.
En el caso de Oracle Database@AWS, como es un servicio gestionado dentro de AWS, sigue esa misma lógica: sus eventos van al event bus por defecto de tu cuenta.
❌ A) Al event bus creado con prefijo aws.partner/odb
Por qué es incorrecta:
Los event buses con prefijo aws.partner/… se utilizan solo para integraciones de partners externos (por ejemplo, servicios SaaS como Datadog, Zendesk, o PagerDuty).
En este caso, Oracle Database@AWS no es un partner externo, sino un servicio gestionado dentro de AWS.
Por eso, no usa un partner event bus.
❌ C) A un event bus específico creado exclusivamente para Oracle Database
Por qué es incorrecta:
AWS no crea un event bus dedicado para cada servicio.
Todos los servicios integrados con EventBridge publican eventos en el event bus por defecto, a menos que tú configures algo distinto.
No existe un “event bus exclusivo de Oracle Database”.
❌ D) A todos los event buses disponibles en la región
Por qué es incorrecta:
Cada evento se envía a un único event bus, no se distribuye automáticamente a todos.
Si los eventos se enviaran a todos los buses, habría duplicidad y confusión en el enrutamiento.
Por diseño, AWS EventBridge es determinista: un evento pertenece a un solo bus de eventos.
¿Cuáles son los tipos de cambios de ciclo de vida de red en ODB que generan eventos en AWS? (Selecciona tres)
A) Creación exitosa de la red ODB
B) Fallo en la creación de la red ODB
C) Eliminación exitosa de la red ODB
D) Cambios en la configuración de seguridad de la red
A
¿Cuál es el prefijo específico del event bus que se crea automáticamente en la cuenta de AWS del cliente cuando se suscribe a Oracle Database@AWS?
A) aws.oracle/odb/event-bus
B) aws.partner/odb
C) aws.database/oracle
D) aws.oracledb/events
B
¿Qué API de Amazon EventBridge se utiliza para crear y aplicar un patrón de filtro basado en el tipo de evento?
A) put-event
B) put-rule
C) create-filter
D) apply-pattern
B
¿Cuáles de los siguientes son tipos de eventos que se pueden monitorear en el event bus aws.partner/odb cuando se generan en OCI? (Selecciona tres)
A) Oracle Exadata Infrastructure events
B) VM Cluster events
C) Container Database events
D) AWS EC2 instance events
A
En una Pluggable Database (PDB) monitoreada a través de CloudWatch, ¿cuál es la combinación de métricas que mejor indica el tiempo de ejecución de consultas y la contención de recursos?
A) Parse Count y Execute Count exclusivamente
B) DB Time Seconds y Wait Time Seconds
C) User Calls y Logical Block Reads
D) Flash Recovery Area y IOPS and IO Throughput
B
El Concepto Clave: Tiempo de Base de Datos (DB Time)
En el mundo de Oracle, la métrica más importante para entender el rendimiento es DB Time (Tiempo de Base de Datos).
DB Time: Es el tiempo total que todas las sesiones de usuario (foreground) han pasado activas, ya sea trabajando en la CPU o esperando por un recurso.
Piensa en una autopista:
DB Time es el tiempo total que todos los coches pasaron en un tramo de 10km.
Cuando analizas el rendimiento, la pregunta principal es: “¿En qué se está gastando el DB Time?” Y solo hay dos respuestas posibles:
CPU Time: Tiempo trabajando (el coche avanzando).
Wait Time: Tiempo esperando (el coche en un atasco).
✔️ Por qué B es la respuesta correcta
B) DB Time Seconds y Wait Time Seconds
Esta combinación responde perfectamente a las dos partes de la pregunta:
“Tiempo de ejecución de consultas”: DB Time Seconds es la mejor métrica para esto. Mide el costo total o la carga de trabajo de la base de datos. Si DB Time es alto, significa que la base de datos está dedicando mucho tiempo a procesar solicitudes, lo cual está directamente relacionado con la ejecución de consultas.
“Contención de recursos”: Wait Time Seconds mide esto directamente. Es, por definición, el tiempo que las sesiones pasaron esperando por algo que les impedía ejecutarse (ej. esperando a que un disco lea un bloque, esperando a que se libere un bloqueo, etc.). Si el Wait Time es un porcentaje alto del DB Time, tienes un problema de contención de recursos (un atasco).
Por lo tanto, DB Time te dice “cuán ocupada” está la base de datos, y Wait Time te dice “cuán atascada” está. Es la combinación perfecta.
❌ Por qué las otras respuestas son incorrectas
A) Parse Count y Execute Count exclusivamente
Qué mide: Cuántas veces se analizó (parse) y ejecutó una consulta.
Por qué es malo: No mide tiempo. Un millón de ejecuciones (Execute Count alto) de una consulta de 1 milisegundo es una carga de trabajo trivial. Una sola ejecución de una consulta de 1 hora es un problema masivo. Los contadores no te dicen nada sobre el costo (tiempo) o la contención.
C) User Calls y Logical Block Reads
Qué mide: Cuántas veces el usuario “llamó” a la base de datos y cuántos bloques de datos se leyeron desde la memoria (lectura lógica).
Por qué es malo: Al igual que la A, son contadores de actividad. Muestran cuánto trabajo se hizo en memoria, pero no miden el tiempo que tomó ni la contención (ej. lecturas físicas de disco, que son las lentas).
D) Flash Recovery Area y IOPS and IO Throughput
Qué mide: Flash Recovery Area (FRA) mide el espacio en disco para backups, lo cual es irrelevante para el rendimiento de consultas. IOPS/Throughput (Operaciones de E/S por segundo y rendimiento) son métricas del sistema operativo o del hardware de almacenamiento.
Por qué es malo: FRA es incorrecto. IOPS te dice qué está haciendo el disco, pero no te dice si la base de datos está esperando por él. Podrías tener un IOPS bajo y una contención altísima (ej. por bloqueos) o un IOPS altísimo que está siendo manejado perfectamente sin esperas. Wait Time (de la opción B) es la métrica que te dice si el IOPS es realmente un problema.
¿Cuántos días de registros de eventos de auditoría se pueden ver, buscar y descargar directamente desde el CloudTrail Event History sin configuración adicional?
A) 30 días
B) 60 días
C) 90 días
D) 180 días
C
¿Cuál es la solución recomendada para retener registros de CloudTrail más allá del período estándar de 90 días en Oracle Database@AWS?
A) Configurar CloudWatch para almacenar los registros indefinidamente
B) Crear un CloudTrail trail o un CloudTrail Lake event data store
C) Replicar manualmente los registros a un bucket de S3 adicional
D) Utilizar EventBridge para archivar eventos automáticamente
B
¿Qué tipo de operaciones en Oracle Database@AWS se registran como management events en AWS CloudTrail?
A) Solo las consultas SELECT ejecutadas en las bases de datos
B) Las operaciones del plano de control (control plane operations)
C) Únicamente los cambios en los parámetros de instancia
D) Las operaciones de backup y recuperación exclusivamente
B
¿Cuál de las siguientes afirmaciones describe correctamente la relación entre AWS CloudTrail e Oracle Database@AWS?
A) Oracle Database@AWS está parcialmente integrado con CloudTrail y solo registra operaciones críticas
B) Oracle Database@AWS está completamente integrado con CloudTrail, capturando todas las llamadas a API
C) CloudTrail solo registra eventos de bases de datos autónomas, no de Exadata
D) Oracle Database@AWS no utiliza CloudTrail; en su lugar utiliza servicios de auditoría propios
B
-
Introduction to Oracle Database@AWS188
-
Getting started with Oracle Database@AWS220
-
Advanced Networking71
-
Security in Oracle Database@AWS161
-
Migration to Oracle Database@AWS148
-
Backup and Restore for Oracle Database@AWS208
-
High Availability and Disaster Recovery of Oracle Database@AWS Database Resources139
-
Monitoring Oracle Database@AWS106
-
Architectural Best Practices163
-
preguntas prueba + IA271
-
refuerzo166
