CDL sample questions — 25 answered and explained

Open source concerns access to code; open standards concern publicly available specifications for interoperability.

Open source code comes with a license that grants the rights to use, modify and share it, so 'no license terms' is wrong. An open standard is a specification, not code, and anyone can implement it, including vendors that keep their own code private. A format one vendor controls for its own customers is the opposite of open.

1. Define open source: licensed access to code.
2. Define open standard: a public specification for interoperability.
3. Check each statement against these definitions, watching for code and specification being swapped.

Exam tip: Open source can implement open standards, but the two terms answer different questions: who can see the code, and who can implement the spec.

Scalability is the ability to increase or decrease resources as demand changes; in the cloud this can happen in minutes and often automatically.

The site needs much more capacity for a few hours and much less the rest of the time. Cloud scalability lets it add resources for the sale and release them afterward, paying only for what it used. Global reach, security and analytics are real benefits but do not address a demand spike.

1. Identify the problem: short, large demand spikes.
2. Match it to the benefit that changes capacity with demand.
3. Eliminate benefits about location, protection or analysis.

Exam tip: Variable or spiky demand points to scalability.

Cloud computing moves IT spending from capital expenditure (CapEx: buying hardware ahead of need) to operating expenditure (OpEx: paying for resources as they are used).

Buying servers up front ties up capital and forces guesses about future demand. With the cloud, the manufacturer pays for what it uses, when it uses it. Financing the same servers keeps the old fixed-capacity model, a fixed fee regardless of use is not how cloud resources are billed, and the reversed statement describes the old model.

1. Name the current model: capital spending ahead of need.
2. Recall the cloud model: operating spending that follows use.
3. Reject the reversed statement, the financed lease and the fixed fee.

Exam tip: Cloud turns up-front CapEx into pay-as-you-go OpEx.

Agility is the ability to respond quickly to change; in the cloud, resources can be provisioned on demand in minutes instead of weeks.

The bottleneck is the lead time to get servers. Cloud agility removes it because teams provision resources themselves when they need them and release them afterward. Pay-per-use helps cost, availability helps resilience and global reach helps users far away, but none of them shortens the wait.

1. Find the bottleneck: weeks of waiting for servers.
2. Match it to the benefit about speed of provisioning.
3. Eliminate benefits that address cost, resilience or location.

Exam tip: Faster experimentation and time to market point to agility.

Data-driven insight means turning data into timely decisions; the cloud helps by unifying data and providing analytics that can work in near real time.

The problem is fragmented data and slow reporting. Bringing the data into one platform lets the chain analyze trends across stores as they happen. Moving each system separately, adding local storage or giving each store its own spreadsheet all keep the data siloed.

1. Identify the problem: data silos and delayed reporting.
2. Choose the option that removes the silos and speeds up analysis.
3. Reject options that keep data separated by store.

Exam tip: Insights need unified data; moving silos to the cloud keeps them silos.

A data lake is a central repository that holds raw structured, semi-structured and unstructured data in its original format.

The clues are 'original formats', mixed data types and 'until analysts decide how to use them'. That is the definition of a data lake. The warehouse and data mart are tempting because they are also central analytical stores, but both expect data to be cleaned and structured before loading.

1. Note the mixed data types, including video and posts.
2. Note that the data is kept in its original format.
3. Note that its use is not yet decided.
4. Match those clues to a data lake.

Exam tip: Raw data, any format, use decided later: that is a data lake.

Data lakes are schema-on-read: raw data is stored first and structured when used. Data warehouses are schema-on-write: data is modelled before it is loaded.

The key difference is when structure is applied. A lake stores raw data of any type and applies structure when it is read. The data-mart description is tempting because a mart is also an analytical store, but it holds curated warehouse data. The transaction option describes an operational database, and published reports are BI outputs, not stored raw data.

1. Recall what a warehouse and a data mart store: cleaned, modelled, structured data.
2. Recall what a lake stores: raw data of any type.
3. Note when structure is applied in a lake: at read time.
4. Pick the statement that describes the lake, not a mart, database or BI tool.

Exam tip: Lake: store first, structure later. Warehouse: structure first, then store.

A data lake keeps raw data of any type, but it still needs governance: a catalogue, metadata, ownership and access policies. Without them it becomes a 'data swamp' that holds data nobody can find, trust or safely use.

Both problems in the scenario are governance problems: analysts cannot judge which data is reliable, and compliance cannot locate personal data. A catalogue with metadata, owners and access policies solves both. A fixed load-time schema is the tempting near-miss because it sounds like adding order, but it turns the lake into a warehouse and still names no owner or sensitive data. A faster engine and per-department lakes leave the governance gap in place.

1. Identify the two problems: unknown reliability and unknown personal data.
2. Recognise both as missing metadata, ownership and access control.
3. Recall that lakes stay schema-on-read but still need governance.
4. Reject options that change speed, schema or layout without adding governance.

Exam tip: A lake without a catalogue, owners and access rules becomes a data swamp.

Data is classified by who collected it: first-party (you, from your own customers), second-party (a partner's first-party data shared with you), third-party (compiled by an aggregator).

The chain gathered the data from its own customers through its own app, which is first-party data. Second-party is tempting because loyalty programmes often involve partners, but here no partner is involved. Zero-party describes information customers deliberately choose to share, not transaction history the app records.

1. Ask who collected the data.
2. Note that it came from the chain's own customers via its own app.
3. Match that to first-party data.

Exam tip: Your own customers, your own channels: first-party data.

Third-party data is collected and aggregated by an entity that has no direct relationship with the data subjects, then sold or licensed to others.

The clues are 'buys', 'data broker' and 'compiled from many sources', which define third-party data. Second-party is the tempting near-twin because it also comes from outside the organization, but it is one partner's own first-party data shared directly, not an aggregated broker product.

1. Ask who collected the data and how.
2. Note it was aggregated by a broker from many sources.
3. Recall that aggregated, purchased data is third-party.

Exam tip: Bought from an aggregator: third-party data.

In customer support, agentic AI changes the job from answering questions to resolving them: agents can take actions such as rebooking, refunding or updating accounts.

The deciding requirement is resolution in the same conversation without a human. Only an agent that acts on the booking meets it. Routing and translation are useful but still hand the work to people, and cancellation reports serve managers rather than the customer.

1. Find the requirement: resolve the request in the conversation, no human.
2. Ask which option actually completes the task.
3. Reject options that pass the work to people later.
4. Choose the agent that checks, decides and acts.

Exam tip: Agentic AI in support means the issue gets resolved, not just answered or routed.

Agentic AI reshapes work across functions such as research, sales, customer support and operations by handling multi-step, goal-driven tasks that earlier automation could not.

Agentic AI works toward a goal by gathering information, reasoning over it and taking several steps, as in the research summary and the scheduled sales follow-ups. An FAQ chatbot and a prediction model are AI too, but each produces a single output for a person to use and takes no further action. A fixed rule is earlier automation.

1. Look for goal-driven, multi-step work that gathers information and acts on it.
2. Keep the research summary and the prepared, scheduled sales follow-ups.
3. Reject the FAQ chatbot and the prediction model: AI that returns one output and takes no action.
4. Reject the fixed rule as earlier automation.

Exam tip: Not all AI is agentic: an agent gathers, reasons and takes steps toward a goal, while a chatbot or prediction model returns one output.

One key benefit of Google Cloud's AI offerings is purpose-built infrastructure for AI, including Google-designed TPUs and GPUs, available on demand.

The need is compute for training and serving the organization's own large models. That is the infrastructure benefit. The data cloud prepares data, Gemini models replace training rather than enabling it, and pre-built agents are finished applications.

1. Identify the need: hardware to train and serve the organization's own models.
2. Match accelerator hardware to Google Cloud's AI infrastructure.
3. Reject options about data, ready-made models or finished applications.
4. Choose the infrastructure benefit.

Exam tip: Training and serving your own large models points to Google Cloud's AI infrastructure: TPUs and GPUs on demand.

Google Cloud's AI offerings span layers: infrastructure, a data cloud, first-party models, a developer platform for building, and pre-built agents and applications that people use directly.

Two constraints decide: results within weeks and no team to build models. Pre-built agents and applications meet both. The developer platform is the near-twin: it is the right layer for building agents, but building is exactly what this company cannot do. Infrastructure and the data cloud are foundations for builders, not tools staff can use.

1. Note the constraints: fast results and no build team.
2. Ask which layer gives employees AI without any building.
3. Reject the layers that support teams who build: platform, infrastructure and data.
4. Choose pre-built agents and applications.

Exam tip: No team to build and a short timeline point to the pre-built agents and applications layer.

AI is only as useful as the data it can reach. An AI-ready data cloud unifies and governs an organization's data so models and analysts can use it without manual assembly.

The root cause is data scattered across systems. The data cloud benefit addresses it directly. The other options are real benefits that improve later stages (training speed, model capability, building and deployment), so they are tempting, but the wasted time happens before any of those stages begin.

1. Locate where the time is lost: before model work, assembling data.
2. Name the root cause: data in separate systems.
3. Match unifying data to the AI-ready data cloud.
4. Reject benefits that speed up later stages.

Exam tip: When teams lose time assembling scattered data, the benefit that helps is an AI-ready data cloud.

Rehosting is fast but carries over the workload's existing design and sizing, so cost and elasticity gains usually need a later optimization step.

Lift and shift deliberately changes nothing. Servers sized for an on-premises peak stay oversized, and monolithic designs still scale only by buying bigger machines. That is why rehosted workloads are commonly right-sized and then replatformed or refactored later. The distractors describe other approaches or misstate Spot pricing.

1. Recall what lift and shift changes: only where the workload runs.
2. Connect unchanged sizing to higher-than-expected cost.
3. Connect unchanged design to limited elasticity.
4. Reject options describing refactor, replatform or wrong pricing.

Exam tip: Lift and shift moves your inefficiencies too; optimize after the move.

Replatform (move and improve) moves a workload with targeted optimizations, such as a managed database, without redesigning the application.

The giveaway is the combination: the workload moved, one component was swapped for a managed service, and the code barely changed. That is more than a rehost and much less than a refactor.

1. Confirm the workload moved to the cloud.
2. Note the one targeted improvement: a managed database.
3. Note the code is largely unchanged, ruling out refactor.

Exam tip: Moved plus a few targeted upgrades, code mostly unchanged: replatform.

Replatforming to managed services cuts operational toil without the cost of rewriting the application.

Two constraints decide it: less database upkeep, and no rewrite. Rehosting meets the budget but not the upkeep goal. Refactoring meets the upkeep goal but breaks the budget. Replatforming onto a managed database meets both.

1. List the two goals: less upkeep, no rewrite.
2. Test each approach against both goals.
3. Keep the one that passes both: replatform with a managed service.

Exam tip: Want less upkeep without a rewrite? Replatform onto managed services.

Refactor changes an application's code and architecture, for example into microservices, to gain cloud-native benefits such as independent releases and scaling.

Several options help with traffic spikes, which is why this is a trade-off. The deciding requirements are independent releases and scaling parts separately; only an architecture change delivers them. The stated willingness to accept a longer, costlier migration removes the usual reason not to refactor.

1. Separate the two problems: spikes and all-or-nothing releases.
2. Note that bigger VMs or autoscaling address spikes only.
3. Identify that independent releases require changing the architecture.
4. Use the accepted cost and time to confirm refactoring is acceptable.

Exam tip: If the goal needs a different architecture, only refactoring delivers it; rehost and replatform keep the monolith.

Unsecured third-party systems are partners' or suppliers' tools and services connected to an organization; their weak security becomes the organization's risk.

The deciding detail is whose system was weak: a supplier's remote-support tool. Organizations inherit risk from every connected third party, so supplier access must be controlled and reviewed like internal access.

1. Find the entry point: a supplier's connected tool.
2. Note the weakness: a weak, shared password.
3. Match a partner's weak system used as a way in to third-party risk.
4. Choose unsecured third-party system.

Exam tip: Your security is only as strong as the suppliers you connect to it.

LLM attacks include prompt injection (crafted input that makes a model ignore its instructions) and data poisoning (corrupting training data); both can leak data or cause harmful output.

The attacker manipulates the model at run time with text that overrides its rules. That is prompt injection. Data poisoning is the near-twin, but it tampers with what the model learns from, not with what a user sends it.

1. Note the attack is a message sent to an AI model.
2. Note the message overrides the model's instructions.
3. Separate run-time manipulation from training-data tampering.
4. Choose prompt injection.

Exam tip: Input that talks a model out of its rules = prompt injection.

AI systems face attacks on their data and inputs: data poisoning targets training data, prompt injection targets run-time input.

The attacker changed what the model learned from, so the trained model approves fraud. That is data poisoning. Prompt injection is the tempting near-twin, but it works through a user's input at run time, not through training data.

1. Locate the tampering: historical training data.
2. Note the effect appears after retraining.
3. Map tampering with training data to data poisoning.
4. Reject prompt injection, which acts at run time.

Exam tip: Corrupt what the model learns from = data poisoning; corrupt what it's told = prompt injection.

Moving to the cloud changes security from owning every layer to a shared responsibility (Google also uses the term shared fate): the provider secures the underlying infrastructure, and the customer secures what it puts in and configures.

On premises the company owned every layer, from locks on the doors to user permissions. In Google Cloud, Google takes the physical and infrastructure layers, while the customer keeps its data, identities and configuration. Neither extreme (Google does everything, or nothing changes) is right.

1. Recall the on-premises baseline: the company owns every layer.
2. Recall what Google takes on: facilities, hardware, infrastructure.
3. Recall what stays with the customer: data, identities, access settings.
4. Choose the shared split.

Exam tip: In the cloud, Google secures the cloud; you secure what you put in it and how you configure it.

Technology alone does not control cloud costs; it needs people who own the costs and processes that turn alerts into action.

The company has the technology: budgets, alerts and dashboards. Costs still grow because alerts reach no one accountable and there is no routine for responding. Adding thresholds, data exports or labels adds more technology to a problem that is about ownership and process.

1. Note what already works: alerts and dashboards.
2. Note what fails: nobody acts on the alerts.
3. Recall that cost control needs people and process as well as technology.
4. Choose owners plus a routine for acting.

Exam tip: Cost tools only save money when someone owns the response and a process makes it happen.

Cloud Billing reports give a visual view of cost trends, grouped and filtered by project, service, SKU or label.

The need is a cost trend over time, split by project and service. Cloud Billing reports provide exactly that view in the Billing console. Budgets and alerts are a cost tool too, but they compare spend with a target rather than chart history. Cloud Monitoring and Cloud Audit Logs report performance and activity, not spending.

1. Identify the need: cost over time, by project and service.
2. Recall which tool reports billed costs.
3. Reject tools that report metrics or activity, and budgets that only compare spend with a target.
4. Choose Cloud Billing reports.

Exam tip: To see where cloud money goes over time, use Cloud Billing reports.