Automation and configuration management replace the manual, repetitive work of logging into servers to install software and fix settings. For the PCDOE exam, you must know how to use Google Cloud tools like Cloud Functions and Cloud Scheduler to make operations hands-free so your systems stay consistent and your team can sleep at night. This chapter explains these tools in plain language, showing you exactly what the exam expects you to remember.
Jump to a section
A simple way to picture Automation and Configuration Management with Cloud Tools
You order a meal kit delivery service. The box arrives with every ingredient pre-measured and individually packed – 100 grams of rice in one bag, 2 tablespoons of soy sauce in a tiny bottle, and a recipe card with pictures. In the old way of cooking, you'd go to the supermarket, wander the aisles, compare brands, check your pantry for what you already have, and hope you didn't forget the ginger. That is like manually logging into 50 servers to install software and tweak config files. The meal kit automates the shopping and preparation steps. But what happens when you want to cook the same meal for ten friends? You don't order ten separate boxes and cook ten identical meals in ten different pans. You scale the recipe – double the ingredients, use a bigger pot, and set a single, reliable timer. This is infrastructure as code (IaC) and configuration management. You write one ‘recipe’ – a script or configuration file – that describes your entire server setup: which operating system, which security settings, which application version. Then you run that one recipe against ten, a hundred, or a thousand servers simultaneously. The recipe ensures every server is identical, just like the same meal kit recipe guarantees every dinner plate tastes the same. If a server breaks, you don't fix it manually; you throw it away, grab a new one, and re-run the recipe. The system becomes predictable, repeatable, and boringly consistent – exactly what a DevOps engineer wants.
Cloud Scheduler is the alarm clock in this story. You don't wake up at 3 AM to start the slow cooker; you program the appliance to start cooking automatically. Cloud Scheduler triggers your automation scripts at precise times – every hour, every day, or on the first Monday of the month. Cloud Functions are the tiny robot chefs that handle individual tasks: when the timer goes off (Cloud Scheduler sends a message), the robot chef (Cloud Function) runs the recipe (your code) to perform a single job, like restarting a database or clearing old logs. Together, they turn a manual, error-prone process into a reliable, automated kitchen that runs while you sleep.
Configuration management is the practice of defining and maintaining the desired state of your computer systems – servers, databases, network devices – using code instead of clicking around in a graphical user interface (GUI). Think of it as writing a detailed instruction manual for every machine. In the old days, a sysadmin would log in to each server by hand, install packages, edit text files, and pray nothing broke. That approach is slow, error-prone, and impossible to repeat identically across hundreds of machines. Configuration management tools like Chef, Puppet, Ansible, and SaltStack automate this process. You write a single file – called a manifest, a playbook, or a policy – that describes exactly how a server should be configured. For example, ‘Install Apache version 2.4.6, enable HTTPS, set the document root to /var/www/html, and open port 443 in the firewall.’ The tool then ensures every server matches that description. If a server drifts from the desired state – someone accidentally changes a file – the tool corrects it automatically. This is often called ‘infrastructure as code’ (IaC), because you manage your infrastructure the same way developers manage application code: in version control, with peer review, and in repeatable units.
Google Cloud provides several managed services that help you implement automation and configuration management without building the whole system yourself. Cloud Functions is a serverless compute platform – ‘serverless’ means you do not manage any underlying servers; you just upload your code and Google runs it when needed. A Cloud Function is triggered by an event, such as a new file appearing in Cloud Storage, a message arriving in Pub/Sub (a messaging service), or an HTTP request (a web call). Each function runs a single, focused task. For example, a function could resize an image when it is uploaded, or send an alert when a log contains the word ‘error’. Functions are stateless – they do not remember anything between runs – and they automatically scale to handle many invocations at once. You pay only for the time your code executes.
Cloud Scheduler is a fully managed cron job service. A cron job is a scheduled task that runs at a specific time, repeatedly – think of it as a super-reliable alarm clock for your cloud infrastructure. You define a schedule using a standard cron format (e.g. ‘0 3 * * 1’ means every Monday at 3 AM). When the time comes, Cloud Scheduler sends an event – typically an HTTP request or a Pub/Sub message – to trigger a Cloud Function, run a script, or call an API (application programming interface, a way for programs to talk to each other). This allows you to automate routine maintenance tasks like rotating log files, taking database backups, or cleaning up unused resources. Together, Cloud Scheduler and Cloud Functions form a powerful combination for event-driven automation: the scheduler provides the time trigger, the function executes the action.
Configuration management in Google Cloud also includes tools like Deployment Manager and HashiCorp Terraform (a popular third-party IaC tool that works with GCP). Deployment Manager lets you describe all your cloud resources – virtual machines, networks, storage buckets – in a YAML or Python configuration file. You declare what you want (e.g., ‘I want 3 virtual machines, each with 4 CPUs and 16 GB of RAM, connected to a specific network’), and Deployment Manager creates them in the correct order with dependencies resolved automatically. This eliminates the ‘snowflake’ problem, where every server is unique because it was manually configured and no two people did it the same way. With IaC, every environment is identical: development, test, and production all match the same configuration file. If you need to change a setting, you edit the file, review it in a pull request, and apply it to all environments simultaneously. The PCDOE exam tests your understanding of when to use Cloud Scheduler vs. Cloud Functions vs. other automation options, and how to combine them with configuration management principles.
Identify the Task and Trigger
Decide what operational task needs automating (e.g., daily database backup) and what will trigger it (time-based schedule, file upload, error log). For the PCDOE exam, recognising the trigger type is the first step. Time-based triggers point to Cloud Scheduler; event-based triggers point to Cloud Functions or Pub/Sub.
Write the Automation Code or Script
Create a small, focused script (e.g., Python, Node.js, Go) that performs the task. For the backup example, the script connects to the database, exports data, compresses it, and uploads to Cloud Storage. The script must be idempotent – running it twice should produce the same outcome, not duplicate backups.
Package the Code as a Cloud Function
Place the script inside a Cloud Function. Define the entry point (the function that runs when triggered). Set environment variables (e.g., database hostname, storage bucket name) and specify runtime (e.g., Python 3.11). Cloud Functions automatically handle authentication if you use the right IAM roles on the function's service account.
Create a Cloud Scheduler Job
In the Google Cloud Console, create a new Scheduler job. Set the frequency using cron syntax (e.g., '0 3 * * *' for daily at 3 AM). Choose the target type: HTTP (to call the Cloud Function's URL) or Pub/Sub (to publish a message that triggers the function). Configure authentication so the Scheduler can invoke the function.
Define and Apply Infrastructure as Code
Write a Deployment Manager or Terraform configuration file that describes the entire environment – the Cloud Function, Scheduler job, storage bucket, and any required IAM roles. Store this file in a Git repository. Apply the configuration to create all resources. This ensures the automation infrastructure itself is reproducible and change-managed.
Test, Monitor, and Iterate
Manually trigger the Cloud Function to verify it works. Check that Cloud Scheduler runs at the correct time. Set up Cloud Monitoring alerts to notify you if the function fails or the scheduler misses a job. Review logs in Cloud Logging to spot issues. Adjust the script or schedule as needed based on real-world behaviour.
Let us walk through a realistic scenario at a mid-sized retail company that sells products online. The company runs its application on Google Kubernetes Engine (GKE), managed MySQL databases, and uses Cloud Storage for product images. The DevOps team has three major automation challenges: daily database backups, weekly security patch updates on the application servers, and hourly log rotation to avoid filling up disk space. In the past, a junior admin stayed late every Sunday night to manually run scripts. The company decides to automate these tasks.
Step-by-step, here is what the team does:
They write a Python script that connects to the MySQL database, dumps the contents, compresses the file, and uploads it to a specific Cloud Storage bucket. The script runs in a Cloud Function.
They create a Cloud Scheduler job with the cron schedule ‘0 3 * * *’ (every day at 3 AM). The scheduler sends an HTTPS request to the Cloud Function’s endpoint, triggering the backup script.
For security patches, the team uses Deployment Manager with a YAML configuration file that specifies the desired operating system image and installed package versions for the virtual machines in the application tier. They set up a weekly Cloud Scheduler job that deploys the latest configuration, ensuring any new security patches are applied automatically.
For log rotation, they use a Cloud Function triggered by a Pub/Sub message. Cloud Logging (the system that collects all logs) publishes a message every hour to Pub/Sub. The function reads archived logs, compresses them, and moves them to long-term storage in a Nearline storage bucket (a cheaper storage class for infrequently accessed data).
The team also uses Infrastructure as Code (IaC) for their entire environment. They store a Terraform configuration file in a Git repository. When a developer needs a new test environment, they run ‘terraform apply’ on that file, and the exact same network, firewall rules, and VM sizes are created, matching production. This eliminates configuration drift – the gradual, unplanned changes that make environments inconsistent over time. When a production incident occurs, a senior engineer can roll back by reverting the Terraform configuration file to a previous version and re-applying it.
In this real scenario, the team never logs into a server manually except for emergency troubleshooting. Automation handles the boring, repetitive tasks, and configuration management ensures all servers look identical. The result: fewer human errors, faster recovery from failures, and lower cost because no one is paying overtime for manual patching. For the PCDOE exam, you need to recognise that Cloud Functions are best for event-driven, short-lived tasks, Cloud Scheduler is for time-based triggers, and configuration management tools like Deployment Manager or Terraform are for maintaining consistent infrastructure over its entire lifecycle.
The PCDOE exam tests your understanding of automation and configuration management in a very applied way. Expect multiple-choice questions that give you a business requirement and ask you to choose the most appropriate Google Cloud service. For example, ‘A team needs to run a script every hour to check for unused disks. Which service should they use?’ The correct answer is usually Cloud Scheduler combined with Cloud Functions. The trap is that many questions offer Cloud Tasks (a queuing service) or Cloud Workflows (a service for orchestrating multiple steps) as alternatives. You need to know that Cloud Scheduler is the right choice for time-based schedules, while Cloud Tasks is for message queues with variable delays.
Key concepts the exam loves:
Desired state vs. current state: configuration management tools constantly compare what the system should be (the desired state) against what it currently is, and fix any drift. Questions will describe a situation where a server’s settings get changed by a manual action, and ask how to restore them automatically. The answer involves a configuration management tool that runs periodically or a Cloud Function that applies the desired state.
Event-driven vs. time-driven automation: Cloud Functions are event-driven (e.g., a file upload triggers a function); Cloud Scheduler is time-driven (e.g., run at 3 AM). The exam will mix these up, asking for the service that ‘runs code in response to a file being uploaded’ (Cloud Functions) versus ‘runs code at a specific time every day’ (Cloud Scheduler + Cloud Functions).
Serverless trade-offs: Cloud Functions have a maximum execution timeout (currently 9 minutes for first-generation and 60 minutes for second-generation). If a backup script takes 30 minutes, a single Cloud Function might not be appropriate. The exam expects you to recognise that long-running tasks should use Cloud Run or Compute Engine instead.
Identity and Access Management (IAM) automation: Configuration Management tools often create service accounts (special accounts for machines, not people) with specific permissions. The exam tests you on the principle of least privilege – each automation script should only have the minimum permissions it needs. A trap question might offer a role that is too broad, like ‘Project Editor’, instead of a specific role like ‘Storage Object Creator’.
Exam traps to watch for: - ‘Infrastructure as Code’ vs. ‘Configuration Management’: While related, IaC focuses on provisioning infrastructure (VMs, networks), and configuration management focuses on the software and settings on that infrastructure. Some questions will expect you to distinguish between Terraform (IaC) and Ansible (configuration management). - ‘Agent-based’ vs. ‘Agentless’: Some configuration management tools (like Puppet) require an agent installed on each managed server; others (like Ansible, and Google Cloud’s SCP/OS Config) are agentless. The exam may ask which approach is easier to set up (agentless) versus more reliable in disconnected environments (agent-based). - Cloud Scheduler quotas: Scheduler jobs have a maximum frequency (once per minute) and a maximum number of jobs per project. The exam won’t ask the exact numbers, but it may test you on the concept that not all intervals are possible.
To prepare, practise reading scenarios and identifying whether the trigger is time (choose Cloud Scheduler) or event (choose Cloud Functions or Pub/Sub). Memorise that Cloud Functions are stateless and short-lived, and that configuration management tools prevent configuration drift by enforcing a desired state. Avoid overcomplicating – the correct answer is almost always the simplest combination that meets the requirements.
Cloud Functions are serverless, stateless, event-driven code units with a maximum timeout of 9 minutes (1st gen) or 60 minutes (2nd gen).
Cloud Scheduler is a fully managed cron service for time-based triggers that sends HTTP requests or Pub/Sub messages.
Configuration management tools enforce a desired state and correct drift by comparing current configuration against a defined template.
Infrastructure as Code (IaC) tools like Terraform or Deployment Manager provision cloud resources from declarative configuration files.
Automated tasks reduce human error and ensure consistency across environments, but require monitoring and alerting for failures.
When combining Cloud Scheduler with Cloud Functions, the function should be idempotent (can run multiple times without side effects) to handle retries.
Always apply the principle of least privilege: give automation service accounts only the permissions they need, nothing more.
These come up on the exam all the time. Here's how to tell them apart.
Cloud Functions
Event-driven and automatically triggered by Pub/Sub, HTTP, or Storage events
Stateless and short-lived with a 9-minute (1st gen) or 60-minute (2nd gen) timeout
Priced per invocation and compute time in 100-millisecond increments
Cloud Run
HTTP-driven container platform that listens for web requests
Stateful (can handle persistent connections) and supports longer timeouts (up to 60 minutes default, configurable)
Priced per container instance per minute, with idle cost if scaled to zero
Infrastructure as Code (IaC)
Provisions cloud resources like VMs, networks, and storage
Uses declarative files (Terraform, Deployment Manager) to define the resource makeup
Runs only when you apply changes; does not monitor ongoing drift
Configuration Management
Configures software and settings inside existing resources (e.g., install packages, set firewall rules)
Uses policies (Chef recipes, Ansible playbooks) to ensure software state matches the desired state
Runs continuously or on schedule to detect and correct drift
Cloud Scheduler
Designed for fixed, repeating schedules (cron jobs)
Not intended for queue-based ordered processing
Sends triggers at the exact scheduled time with 'at least once' delivery
Cloud Tasks
Designed for distributing work to a queue with optional delays and processing order
Ideal for batching requests and managing retry logic
Sends triggers as messages are pulled from a queue, not on a fixed time
Mistake
Cloud Functions can run arbitrary code forever as long as there is a timeout setting.
Correct
Cloud Functions have a hard timeout. For 1st gen functions it is 9 minutes; for 2nd gen it can be up to 60 minutes, but you cannot run a function indefinitely. Long-running tasks should use Cloud Run or Compute Engine.
Beginners assume 'serverless' means limitless runtime, but the platform imposes limits to prevent resource hogging.
Mistake
Cloud Scheduler is the only way to trigger Cloud Functions on a schedule.
Correct
Cloud Functions can also be triggered by Cloud Tasks, Pub/Sub, and even direct HTTP requests from other services. Cloud Scheduler is the simplest for fixed schedules but not the only option.
People over-fixate on one tool and miss that multiple services can achieve the same goal, which the exam loves to test.
Mistake
Configuration management is the same as infrastructure as code (IaC).
Correct
IaC (e.g., Terraform) provisions the cloud resources themselves – VMs, networks, storage. Configuration management (e.g., Chef, Ansible) configures the software inside those resources – packages, firewall rules, app settings.
The terms overlap in everyday use, but the exam distinguishes them. Confusion leads to choosing the wrong tool for the requirement.
Mistake
I can use Cloud Functions to manage the state of a server because it runs code.
Correct
Cloud Functions are stateless – they do not remember anything between runs. To manage server state, you need a configuration management tool that tracks desired vs. current state and can correct drift over time.
Beginners see 'code runs in the cloud' and assume it can replace dedicated state management tools, but stateless functions cannot enforce ongoing consistency.
Mistake
Automation means I never have to look at the system again.
Correct
Automation handles repetitive tasks, but you still need to monitor logs, handle errors, and update automation scripts when requirements change. Automation reduces manual work but does not eliminate operational oversight.
Newcomers over-romanticise automation as 'fire-and-forget', but the exam focuses on setting up proper error handling and alerting alongside automation.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Cloud Functions runs a single piece of code in response to an event and is intended for short, event-driven tasks. Cloud Run runs a container that listens for HTTP requests and can handle longer processes (up to 60 minutes by default, configurable to hours). Use Cloud Functions for simple triggers; use Cloud Run for full web applications or long-running batch jobs.
Yes. Cloud Scheduler can send messages to Pub/Sub, make HTTP requests to any endpoint (even outside Google Cloud), and invoke App Engine or Cloud Run services. Its primary role is delivering the trigger on schedule.
Not necessarily. A single Cloud Function can handle multiple tasks if you pass different parameters in the trigger event (e.g., which storage bucket to clean). However, the best practice is to keep each function focused on one responsibility for easier testing and debugging.
For 1st gen functions (9-minute limit), you need to break the task into smaller chunks or use Cloud Run with a longer timeout. For 2nd gen functions (60-minute limit), most maintenance tasks fit within the limit. If the script still exceeds 60 minutes, consider using Compute Engine with a startup script or a batch service like Batch.
Use a configuration management tool like Ansible or Chef to apply the same configuration file to all servers. The tool checks each server's current state and corrects any differences. Combining this with infrastructure as code ensures every server starts from the same base image and receives the same software stack.
Cloud Scheduler guarantees 'at least once' delivery, meaning it may occasionally send the same trigger twice. To handle this, design your Cloud Function to be idempotent – it should check if the task has already been done (e.g., if the backup file already exists in the bucket) and skip the duplicate.
You've finished Automation and Configuration Management with Cloud Tools. Continue through the PCDOE study guide to build a complete picture of the exam.
Done with this chapter?