Método

Cómo estudiar para el PCA

El método que sigue esta web: un ciclo semanal de teoría, práctica, test, tarjetas y repaso; cómo leer la documentación oficial, cómo aprovechar Cloud Shell y, sobre todo, cómo razonar las preguntas de escenario como un arquitecto.

La idea en una frase

El PCA no premia la memoria, sino el criterio: ante un escenario con requisitos, elegir la mejor arquitectura. Ese criterio se construye combinando tres cosas: entender cómo funciona cada servicio, haberlo usado y practicar decisiones con preguntas de escenario. Todo el método gira en torno a eso.

El ciclo: teoría → lab → test → tarjetas → repaso

flowchart LR
    T[Teoría: entender] --> L[Lab: usar]
    L --> Q[Test: decidir]
    Q --> F[Tarjetas: recordar]
    F --> R[Repaso: consolidar]
    R -. semana siguiente .-> T
  1. Teoría (lunes a jueves). Lee el módulo con calma. Cada módulo explica el «qué» y el «por qué», trae tablas de decisión «cuándo usar qué» y una lista de trampas típicas del examen.
  2. Lab (sábado). Haz en tu propia cuenta lo que has leído. Ver cómo se crea una subred, qué pide un balanceador o por qué falla un permiso fija los conceptos mucho mejor que leerlos.
  3. Test (domingo). Preguntas de escenario del módulo. Sirven para aprender, no solo para medir: lee todas las explicaciones, también las de las preguntas que aciertas.
  4. Tarjetas (a diario, 15-20 minutos). Las tarjetas usan repetición espaciada: lo que fallas vuelve pronto; lo que dominas, cada vez más tarde.
  5. Repaso (viernes y semana 12). Vuelve a las trampas del examen, a tus fallos y a los apartados donde saques menos nota.

El reparto día a día está en el plan de estudio.

Cómo leer la documentación oficial

La documentación de Google Cloud es enorme. Leerla entera es imposible e inútil para el examen. Úsala así:

  • Empieza por la página Overview de cada producto (por ejemplo, VPC overview): explica qué es, sus conceptos clave y sus límites. Es la página más rentable.
  • Busca las páginas de decisión: Choosing a…, Best practices, Design guide, comparativas de productos. Son exactamente el tipo de conocimiento que pregunta el examen.
  • Lee en inglés. El examen es en inglés y la documentación usa el mismo vocabulario. Evita la versión traducida automáticamente.
  • No memorices cifras sueltas salvo las que definen decisiones (por ejemplo, qué SLA de disponibilidad ofrece una configuración, o qué producto es global y cuál regional).
  • Mira la fecha y los nombres. Varios productos han cambiado de nombre recientemente (Gemini Enterprise Agent Platform, antes Vertex AI; Cloud Run functions; Google Cloud Observability; Google Skills). El examen usa los nombres de la guía vigente.
  • Cada módulo enlaza la documentación clave al final. Ese es tu «mínimo» de lectura oficial.

Cómo aprovechar Cloud Shell

Todos los labs se hacen en Cloud Shell, una máquina Linux en el navegador con gcloud, kubectl, terraform, bq, Git y un editor de código ya instalados. No tienes que instalar nada en tu ordenador. Datos clave (límites de Cloud Shell, verificado el 30/09/2026):

  • Es gratuito, con 5 GB de disco persistente en tu directorio $HOME. Lo que guardes fuera de $HOME se pierde al cerrar la sesión.
  • La cuota semanal es de 50 horas, más que suficiente para este plan.
  • Las sesiones sin actividad se cierran a los 40 minutos y ninguna dura más de 12 horas.
  • Si no lo usas en 120 días, se borra tu $HOME.

Consejos prácticos:

  • Guarda tus scripts de cada lab en una carpeta de $HOME (por ejemplo, ~/pca/lab-07). Te servirán para repasar y para repetir un lab rápidamente.
  • Usa variables de entorno al principio de cada sesión (PROJECT_ID, REGION…), como indican los labs. Si la sesión se cierra, vuelve a definirlas.
  • Abre el Cloud Shell Editor para ver y editar ficheros cómodamente (Terraform, YAML de Kubernetes).
  • Comprueba siempre el proyecto activo con gcloud config list antes de crear o borrar nada.
  • Mira la consola a la vez: lanza el comando en Cloud Shell y comprueba el resultado en la consola web. Así aprendes las dos vías, y el examen da por hecho que conoces ambas.

Aprendizaje activo

Leer y subrayar da sensación de aprender, pero se olvida rápido. Estas técnicas funcionan mejor y están integradas en la web:

  • Recuperación (retrieval practice). Intenta recordar antes de mirar. Los tests y las tarjetas te obligan a sacar la información de tu memoria, que es lo que la consolida. Antes de leer la explicación de una pregunta, di en voz alta por qué crees que es esa.
  • Repetición espaciada. Repasar un poco cada día a lo largo de semanas vale más que un atracón el último fin de semana. Las tarjetas programan los repasos por ti.
  • Explícalo con tus palabras. Al acabar cada módulo, explica en 5 minutos (en voz alta o por escrito) los conceptos principales, como si se lo contaras a un compañero. Donde te atasques, ahí tienes una laguna.
  • Dibuja arquitecturas. Coge papel y dibuja: una VPC con sus subredes y reglas de firewall, una conexión híbrida, un flujo de datos de Pub/Sub a BigQuery. Después, redibújalas de memoria. En el examen «ves» la arquitectura del enunciado mucho más rápido si la has dibujado antes.
  • Estudia los errores. Un fallo en un test es la mejor oportunidad de aprendizaje: apunta por qué elegiste mal (¿no conocías el servicio?, ¿no leíste un requisito?, ¿confundiste dos productos?).

Cómo usar esta web

  • Progreso. En cada módulo, lab y caso de estudio puedes marcarlo como completado. El inicio muestra tu avance por semanas, la mejor nota de cada test y tu último simulacro.
  • Dónde se guarda. El progreso, las notas y el estado de las tarjetas se guardan en tu navegador (almacenamiento local). Si borras los datos del navegador, cambias de navegador o de ordenador, no estarán.
  • Copia de seguridad. En el panel del inicio puedes exportar tu progreso a un fichero JSON e importarlo después. Haz una copia cada semana, por ejemplo el domingo tras el test.
  • Tests por módulo. Tras corregirlos, lee la explicación de cada opción. Tu objetivo es un 80 % o más; si no llegas, repasa los apartados que fallas y repítelo unos días después (no inmediatamente, o recordarás las respuestas en vez de razonarlas).
  • Tarjetas. Repasa las pendientes cada día. Una tarjeta se considera dominada a partir de la caja 3.
  • Simulacro. 2 horas, preguntas de todas las secciones en su proporción del examen, con parte ligada a los casos de estudio. Puedes marcar preguntas para revisar y al final ves la nota por sección. Hazlo en condiciones reales: de una sentada, sin consultar nada.
  • Glosario y buscador. El glosario reúne los términos clave en inglés y español; el buscador de la barra superior encuentra cualquier concepto en toda la web.

Cómo razonar una pregunta de arquitecto

Las preguntas del PCA tienen casi siempre la misma estructura: un escenario, unos requisitos y cuatro opciones que funcionarían todas en algún contexto. Tu trabajo es encontrar la que mejor encaja con este contexto. Sigue estos pasos:

flowchart TD
    A[1. Lee la pregunta final primero] --> B[2. Subraya requisitos del enunciado]
    B --> C[3. Identifica restricciones duras]
    C --> D[4. Descarta opciones que incumplen algo]
    D --> E{¿Quedan varias?}
    E -- Sí --> F[5. Elige la más gestionada y sencilla que cumpla]
    E -- No --> G[Responde]
    F --> G
  1. Lee primero lo que te preguntan (la última frase). No es lo mismo What should you do first? que What is the most cost-effective solution?
  2. Extrae los requisitos. Funcionales (qué debe hacer) y no funcionales: disponibilidad, latencia, escala, coste, seguridad, cumplimiento, plazos, habilidades del equipo.
  3. Detecta las restricciones duras. Son las que eliminan opciones sin discusión: «los datos no pueden salir de la UE», «sin cambios en el código», «RPO de cero», «presupuesto limitado», «el equipo no tiene experiencia con Kubernetes».
  4. Descarta. Normalmente dos opciones caen enseguida porque incumplen una restricción o no resuelven el problema. Ya tienes un 50 %.
  5. Entre las que quedan, elige la más gestionada y sencilla que cumpla todo. Google prefiere servicios gestionados, soluciones nativas, mínimo privilegio, automatización y el menor esfuerzo operativo. Si dos opciones cumplen, suele ganar la que requiere menos piezas y menos mantenimiento.

Algunas pistas de lectura muy habituales:

Si el enunciado dice… Suele apuntar a…
minimize operational overhead, fully managed Servicios gestionados o serverless antes que VM que administras
most cost-effective La opción más barata que cumpla todos los requisitos, no la más barata a secas
without changing the code, lift and shift Migrar tal cual (por ejemplo, a VM) antes que rediseñar
least privilege El rol predefinido más específico, a nivel del recurso, nunca Owner o Editor
first step Lo que va antes de todo lo demás (evaluar, inventariar, definir requisitos)
global users, low latency worldwide Servicios globales: balanceador global, Cloud CDN, bases de datos multirregionales

Recursos oficiales complementarios

Todo esto es gratuito salvo que se indique. La lista completa, con cuándo usar cada uno, está en Recursos.

  • Ruta de Google Skills Professional Cloud Architect Certification (paths/12): cursos, labs guiados e insignias oficiales. Los labs guiados consumen créditos o requieren suscripción (Costes). Útil como segunda explicación de un tema que se te resiste.
  • Preguntas de ejemplo oficiales (formulario): muestran el estilo real de las preguntas. Guárdalas para la semana 10-12, cuando ya tengas visión de conjunto.
  • Cloud OnAir (sesiones del PCA): sesiones de preparación grabadas por Google.
  • Architecture Center (docs.cloud.google.com/architecture): arquitecturas de referencia y el Well-Architected Framework. Ideal para los casos de estudio.

Compaginarlo con el trabajo

  • Mismo sitio, misma hora. Dos horas fijas cada día (antes o después del trabajo) funcionan mejor que «cuando pueda». Si solo tienes una, que sea la de teoría; recupera el resto el fin de semana.
  • Aprovecha los huecos muertos para las tarjetas: transporte, cola del café, esperas. Quince minutos al día sostienen el repaso de todo el temario.
  • Protege el sábado por la mañana para el lab: es la parte que más concentración necesita y la que más cuesta retomar si la cortas.
  • No estudies cansado lo difícil. Si llegas agotado, haz tarjetas o un test corto; deja la teoría densa (redes híbridas, seguridad) para cuando estés fresco.
  • Planifica los imprevistos. Mira en el calendario los puentes, viajes y picos de trabajo de las 12 semanas y ajusta el plan desde el principio.
  • Conecta con tu trabajo. Si en tu empresa usáis otra nube, traduce lo que aprendes: «¿cómo resolveríamos esto en Google Cloud?». Es la mejor práctica de arquitecto que puedes hacer.
  • Descansa. Doce semanas son una carrera de fondo. Si notas agotamiento, convierte el viernes en un día solo de tarjetas y duerme bien antes del lab del sábado.