Governance Risk And Compliance practice questions

Enable self-service password reset.

Why it fails: Permitting self-service password reset on privileged administrative accounts creates an insecure recovery vector that bypasses administrative verification, directly violating SOC 2 Type II audit controls for rigorous access lifecycle management and identity governance. Conversely, this feature is tempting because organisations routinely deploy it for standard end-user populations to automate tier-one helpdesk password recovery, reduce operational support overhead, and maintain productivity. It provides a valid, efficient control for non-privileged identities where rigorous administrative oversight is unnecessary, but it remains strictly unsuitable for high-privilege administrative roles.

Configure password complexity to 16 characters.

Why it fails: Enforcing strict password complexity addresses basic authentication hardening, but SOC2 Type II access lifecycle management specifically requires rigorous auditing of account provisioning, role changes, and timely de-provisioning rather than static credential parameters. Administrators often conflate general password policies with identity governance controls because both contribute to overall directory security. Consequently, mandating a sixteen-character threshold would be the correct configuration when satisfying baseline authentication benchmarks, yet it remains completely ineffective for verifying whether administrative entitlements are actively reviewed, systematically certified, and promptly revoked upon role termination.

Enable Just-In-Time (JIT) access requests.

Why it fails: Configuring Okta Workflows alongside role-based access control facilitates Just-In-Time access requests by dynamically provisioning elevated administrative privileges only when explicitly needed and automatically revoking them after a defined duration. This technical control directly satisfies the SOC2 Type II requirement for rigorous access lifecycle management regarding privileged administrative accounts, ensuring that standing high-level access is eliminated and every elevation event is logged and time-bound for auditability.

Enable S3 Object Lock in compliance mode.

Why it fails: Enabling S3 Object Lock in compliance mode addresses data immutability and prevents accidental or malicious deletion of records by enforcing write-once-read-many (WORM) controls, making it the correct choice for regulatory frameworks like SEC Rule 17a-4 that mandate strict record retention. However, it fails this scenario because it governs data retention states rather than geographic location restrictions, whereas enforcing GDPR data sovereignty compliance requires governing the physical storage region of data workloads via Service Control Policies to prevent cross-border data transit.

Utilize S3 Access Points per region.

Why it fails: Utilising S3 Access Points per region is tempting because they simplify managing access permissions for distinct applications or datasets sharing a common bucket by providing tailored hostnames and policies. In this scenario, however, they fail because Access Points control resource-level permissions rather than enforcing the global, organizational-level guardrails required by the question. Service Control Policies operate at the AWS Organizations root, organizational unit, or account level to restrict service actions globally, whereas S3 Access Points cannot prevent cross-region data exfiltration or mandate residency at the perimeter required for GDPR compliance.

Configure S3 Cross-Region Replication with filter.

Why it fails: Cross-Region Replication moves data between AWS regions, which directly violates GDPR data sovereignty restrictions by unnecessarily propagating personal data outside the jurisdiction where it originated. This feature is tempting because architects routinely use replication to achieve high availability and disaster recovery across geographical boundaries. It would be the correct choice when designing for resilience against regional outages where the destination bucket resides within a legally permissible jurisdiction, rather than restricting data residency to enforce compliance.

Azure Policy for Kubernetes

Why it fails: This is platform-specific and not for IaC scanning.

AWS CloudFormation Guard

Why it fails: This is for CloudFormation, not Terraform.

SonarQube

Why it fails: SonarQube is for application code quality, not IaC security.

VPC Service Controls

Why it fails: VPC Service Controls establishes security perimeters around Google Cloud resources to mitigate data exfiltration risks by restricting service communication, rather than acting as a dynamic identity-aware authorisation engine. It is often confused with Zero Trust because it enforces granular network-level boundaries for API-based services. This component is the correct choice when the primary requirement is to prevent unauthorised data movement across project boundaries or to restrict access to sensitive service data based on network location rather than individual user identity and device posture.

Access Context Manager

Why it fails: Access Context Manager serves as the primary Policy Decision Point by evaluating attributes such as device security posture, IP address, and geographic location before granting access. It satisfies the requirement for context-aware governance by defining granular access levels that integrate directly with Identity-Aware Proxy. Unlike Microsoft Entra ID, which focuses on broader identity federation, Access Context Manager provides the specific GCP-native framework needed to enforce dynamic, attribute-based access control policies across your cloud infrastructure based on real-time environmental telemetry.

Cloud Resource Manager

Why it fails: Cloud Resource Manager functions as a hierarchical organisational tool for managing projects, folders, and organisations rather than evaluating real-time access requests. It lacks the capability to inspect device posture or contextual signals required for a Policy Decision Point. It remains the primary mechanism for enforcing IAM policies across GCP resource hierarchies and managing project-level metadata. Candidates often confuse this with access control because it defines the scope where permissions are applied, but it performs no dynamic runtime authorisation based on user or device state.

Configure Log Analytics workspace to export to Sentinel.

Why it fails: Exporting telemetry from a Log Analytics workspace to Microsoft Sentinel establishes a SIEM pipeline for threat investigation and incident response, but it does not evaluate or enforce NIST SP 800-53 security controls within Microsoft Defender for Cloud. This action is tempting because security architects frequently route monitoring logs to Sentinel for centralised security operations and auditing, which would be the correct choice when building a comprehensive security orchestration and automated response workflow rather than managing regulatory compliance posture.

Assign the 'Security Reader' role to the compliance auditor.

Why it fails: Assigning the 'Security Reader' role grants read-only access to security recommendations and alerts within Microsoft Defender for Cloud, but it fails to address the continuous posture management requirement because it does not enable the actual framework assignments or regulatory compliance assessments needed to evaluate NIST SP 800-53 controls. This option is tempting because the role is the standard Microsoft Entra ID mechanism for granting auditors visibility into security states without risking unauthorized modifications, making it the correct choice for passive log review and report generation tasks.

Physical Layer

Why it fails: Focuses on implementation.

Conceptual Layer

Why it fails: This is for abstract architecture design.

Operational Layer

Why it fails: Focuses on management.

Software Patch Level

Why it fails: Software patch level measures vulnerability state rather than the probabilistic loss frequency and magnitude metrics required by the FAIR framework to calculate probable financial risk exposure. This metric is tempting because maintaining current patches is a fundamental operational security task used to remediate system vulnerabilities and harden infrastructure against known exploits. It would be the correct choice when configuring vulnerability management systems or compliance dashboards to track endpoint hygiene and verify that operating systems meet baseline deployment standards.

Network Throughput

Why it fails: Network throughput measures the volume of data successfully transferred across a system over a specific time period, making it a standard metric for assessing raw communication performance and capacity planning under high-load scenarios. However, it fails in the context of Factor Analysis of Information Risk because the FAIR methodology relies exclusively on quantifying probabilistic loss frequency and magnitude, specifically Loss Event Frequency and Probable Loss Magnitude, rather than physical data transfer rates. While an architect would appropriately utilise throughput metrics when evaluating network infrastructure bottlenecks or designing scalable bandwidth requirements, it holds no mathematical relationship to quantifying financial loss exposure or threat frequency.

Amazon Inspector

Why it fails: Amazon Inspector focuses on identifying software vulnerabilities and unintended network exposure within EC2 instances and container images rather than evaluating infrastructure configuration against PCI DSS compliance benchmarks. It serves as an automated vulnerability management tool designed to detect common vulnerabilities and exposures (CVEs) during the development and deployment lifecycle. While useful for securing the underlying operating system and application packages, it lacks the continuous configuration auditing and automated remediation capabilities required to maintain compliance for system component settings.

AWS Config

Why it fails: AWS Config records resource configuration history and evaluates compliance, but its dashboard reports drift rather than remediating it; remediation requires AWS Config rules paired with SSM Automation. The PCI DSS question asks for a service providing both continuous monitoring and remediation, which AWS Config alone does not deliver.

AWS Artifact

Why it fails: AWS Artifact serves as a central repository for compliance reports and audit artefacts, such as PCI DSS Attestation of Compliance documents, rather than performing active configuration monitoring. It is the correct choice when an organisation needs to retrieve documentation to demonstrate security controls to external auditors during a compliance assessment. Because it lacks the capability to scan infrastructure or trigger automated remediation workflows, it cannot satisfy the requirement for continuous monitoring of system component configurations.

AWS CloudHSM

Why it fails: AWS CloudHSM satisfies the strict separation of duties constraint by providing a dedicated hardware security module where the tenant maintains sole control over cryptographic keys, entirely preventing cloud administrators from accessing or viewing them. Because the organisation retains exclusive root control of the HSM partition, the cloud service provider cannot decrypt the regulated healthcare data or interfere with key lifecycle management, thereby fulfilling HIPAA mandates for administrative domain isolation and tenant-controlled key management in a hybrid architecture.

Azure Key Vault

Why it fails: Relying on Azure Key Vault within a multi-cloud or hybrid architecture fails to enforce the required administrative separation of duties, because Azure administrators retain overarching subscription control and potential access paths to the underlying keys. Administrators are often lured by its native integration for managing secrets and keys in Microsoft environments, where it serves as the correct choice for centralized cryptographic operations and certificate management strictly contained within Azure-native infrastructure rather than a complex hybrid cloud boundary.

AWS KMS with Multi-Region keys

Why it fails: Multi-Region keys enable cryptographic material to be replicated across AWS regions for disaster recovery and global application architectures, which makes them tempting for resilient cloud deployments. However, they fail in this scenario because they allow administrators to manage key policies and access parameters within the same cloud provider hosting the encrypted data, thereby violating the strict administrative segregation required to prevent single-party access to regulated healthcare records.

Cloud Interconnect

Why it fails: Cloud Interconnect provides dedicated physical connectivity between an on-premises data centre and Google Cloud, rather than enforcing granular traffic filtering between internal VPC networks. While it serves as a robust solution for extending private network reach and increasing bandwidth for hybrid cloud workloads, it lacks the capability to manage L7 network policies or isolate traffic flows within the GCP environment. Architects typically select this service to ensure low-latency, private communication for enterprise-grade hybrid infrastructure, but it provides no mechanism for intra-cloud VPC governance.

VPC Service Controls

Why it fails: Enforces network perimeters and data isolation.

Cloud Armor

Why it fails: Cloud Armor functions as a web application firewall and DDoS protection service operating at the edge of the network, meaning it lacks the internal routing control required to govern traffic between private VPCs. While it provides robust protection against Layer 7 attacks and malicious web traffic, it does not manage VPC peering or inter-VPC connectivity. Architects often consider this service when they need to secure public-facing endpoints against SQL injection or cross-site scripting, but it remains ineffective for enforcing internal network isolation policies.

Container image manifests

Why it fails: Relying on container image manifests fails because static metadata baked into build-time artifacts cannot dynamically intercept runtime data writes or enforce geographic routing policies when microservices persist Personally Identifiable Information to storage backends. This approach appears appealing because developers frequently use manifests to package deployment configurations and environment variables alongside application code. Such a mechanism would be correct if the objective were to govern static resource allocation, runtime capability constraints, or immutable software supply chain provenance during the initial cluster scheduling phase.

Application service mesh proxy tags

Why it fails: Service mesh proxies operate at the network layer to manage traffic routing and observability, meaning they lack visibility into the underlying data payloads required to enforce GDPR classification policies. While these proxies effectively manage mutual TLS and service-to-service authentication, they cannot inspect application-level data to prevent PII storage in non-compliant regions. This mechanism remains useful for implementing fine-grained traffic policies or circuit breaking, but it fails to provide the data-centric governance necessary for regulatory compliance regarding persistent storage locations.

Infrastructure tags and cloud policy enforcement

Why it fails: Enforcing data classification metadata via infrastructure tags and cloud policy engines, such as Azure Policy or AWS Organizations Service Control Policies, directly satisfies the architectural constraint of preventing personally identifiable information (PII) from being stored in non-compliant geographic regions. By evaluating tags against residency rules at the resource-manager level, cloud policies programmatically block the deployment of non-compliant storage buckets or databases before data ingestion occurs. This automated governance mechanism ensures continuous GDPR compliance across distributed microservices without relying solely on application-tier validation.

Threat Modeling

Why it fails: Threat modelling focuses on identifying and mitigating potential vulnerabilities within an application or system design rather than performing compliance verification. While it is a vital proactive security activity, it lacks the audit-driven validation mechanism required to confirm ongoing alignment with business requirements. This process is the correct choice when the objective is to uncover design flaws or attack vectors during the development lifecycle, ensuring that security controls are integrated to defend against specific threat actors before deployment.

Risk Acceptance

Why it fails: Risk acceptance constitutes a management decision to acknowledge and assume the residual risk after mitigation efforts, rather than a mechanism for verifying architectural alignment through auditing. It remains a tempting choice because it represents a standard component of the risk management lifecycle, typically applied when the cost of further controls exceeds the potential impact of a threat. However, it lacks the evaluative, evidence-based verification processes required to ensure that technical implementations consistently meet defined business objectives.

Compliance Monitoring

Why it fails: Compliance monitoring serves as the primary mechanism for ensuring that architectural implementations remain synchronised with organisational business requirements. By conducting regular audits, this activity satisfies the constraint of continuous alignment verification, systematically identifying deviations between deployed security controls and established governance policies. This process provides the necessary oversight to validate that the technical architecture consistently supports strategic objectives, ensuring that risk management frameworks are effectively enforced and that all infrastructure remains compliant with the defined security posture throughout its operational lifecycle.

Physical security keys for all developers.

Why it fails: Physical security keys operate at the identity and access management layer rather than the automated pipeline orchestration required for Security as Code. While these hardware tokens provide robust multi-factor authentication to secure developer access to repositories and Microsoft Entra ID, they do not integrate security policies directly into the continuous integration/continuous deployment workflow. They are essential for enforcing zero-trust identity verification, yet they remain peripheral to the programmatic definition and automated enforcement of security controls within the infrastructure configuration itself.

Manual approval boards for every change.

Why it fails: Manual approval boards introduce human-centric bottlenecks that directly contradict the automated, continuous delivery requirements of Security as Code. While these boards provide essential governance and risk oversight for high-impact changes in legacy environments or strictly regulated financial sectors, they rely on synchronous human intervention. This approach prevents the rapid, programmatic enforcement of security policies within a CI/CD pipeline, thereby failing to achieve the scalability and real-time compliance automation necessary for a modern, integrated security architecture.

Azure Policy

Why it fails: Azure Policy enforces governance and evaluates compliance across cloud resources by auditing resource configurations against defined rules, but it lacks the execution engine required to actively trigger cryptographic workflows or perform programmatic key rotation. It is a tempting choice because administrators frequently rely on it to mandate compliance standards and flag storage accounts that violate security policies. It would be the correct choice if the objective were solely to audit whether storage account keys have manually exceeded a maximum validity period, rather than executing the automated rotation process itself.

Microsoft Entra ID Privileged Identity Management

Why it fails: Microsoft Entra ID Privileged Identity Management is designed to manage, control, and monitor elevated access to Azure resources rather than automate cryptographic material lifecycle management. While it is tempting because it governs administrative security controls, it provides just-in-time access for user identities rather than executing programmatic, scheduled rotation of underlying storage account access keys. Therefore, it would be the correct choice when an architect needs to enforce time-bound, approval-based activation of administrative roles to prevent standing high-privilege access.

Azure Monitor

Why it fails: Azure Monitor is designed for telemetry collection, metric tracking, and alert generation across cloud resources, making it tempting because architects frequently configure alerts to notify teams when keys are old or when unauthorized access attempts occur. However, it functions purely as an observational and diagnostic tool rather than an orchestration engine; it lacks the capability to execute administrative mutations or interact with the Azure Resource Manager control plane to actively generate and apply new storage account keys.

ISO/IEC 27001

Why it fails: ISO/IEC 27001 establishes requirements for an Information Security Management System rather than providing a governance framework for aligning IT with business objectives. While candidates often conflate the two because both address organisational IT oversight, ISO/IEC 27001 focuses exclusively on risk management and security controls. It serves as the standard for certification bodies auditing information security posture, whereas the COBIT framework specifically addresses the broader governance of enterprise IT and the realisation of business value through strategic alignment.

ITIL 4

Why it fails: ITIL 4 focuses on service management practices and the delivery of value through IT-enabled services rather than the overarching governance of enterprise information and technology. Candidates often select this framework because it provides a structured approach to aligning IT services with business demand. It serves as the correct answer when the question specifies the management of service lifecycles, operational efficiency, or the implementation of service value systems, rather than the governance-level objectives defined by the COBIT framework.

NIST CSF

Why it fails: NIST CSF focuses on managing cybersecurity risk through a voluntary framework of standards and best practices rather than providing the overarching enterprise governance architecture required by COBIT. It serves as a valuable tool when an organisation needs to assess its current security posture or communicate risk management requirements to stakeholders. While it effectively guides the implementation of security controls, it lacks the broader business-IT alignment mechanisms defined within the COBIT framework for governing entire information technology ecosystems.

IAM Permission Boundaries

Why it fails: IAM Permission Boundaries restrict the maximum permissions that an identity-based policy can grant, making this option tempting for limiting what users can provision within member accounts. However, permission boundaries govern principal entities rather than evaluating resource configurations. Consequently, they cannot prevent a principal from creating an S3 bucket with public access or missing encryption, which requires proactive resource-level policy enforcement via AWS Control Tower preventive guardrails such as Service Control Policies.

AWS Config Rules

Why it fails: AWS Config Rules evaluate resource configurations reactively after deployment and lack the enforcement mechanism required to prevent non-compliant S3 bucket creation at the point of provisioning. This feature appears tempting because it excels at continuous compliance monitoring and can detect policy drift across multiple cloud accounts. It would be the correct choice when an architect needs to audit existing environments and automatically trigger remediation playbooks, rather than blocking the initial deployment of insecure infrastructure via preventative control mechanisms.

AWS Security Hub Standards

Why it fails: AWS Security Hub Standards evaluate resource configurations against compliance frameworks like PCI-DSS and generate findings or trigger detective alerts, but they operate as a detective monitoring mechanism rather than a preventative enforcement engine capable of automatically blocking or remediating non-compliant S3 configurations at account creation. This option is tempting because its name directly references PCI-DSS compliance frameworks, making it a logical choice when an architect needs to continuously assess, aggregate, and report on the security posture of existing cloud resources against regulatory benchmarks.

Vendor support availability.

Why it fails: Vendor support availability relates to operational service-level agreements rather than the fundamental risk tolerance required to define an architecture's security posture. While this factor is essential for business continuity planning and vendor management when selecting managed service providers, it does not quantify the organisation's willingness to accept residual risk. Risk appetite statements must instead focus on data sensitivity, regulatory compliance, and threat modelling, which dictate the technical controls necessary for a cloud-native environment, regardless of the level of external support provided.

Technical debt of legacy systems.

Why it fails: Legacy system technical debt focuses on the maintenance burden of monolithic, on-premises infrastructure rather than the inherent risk profile of a greenfield cloud-native architecture. While this factor is essential when formulating a modernisation strategy or decommissioning roadmap for outdated hardware, it lacks relevance to the dynamic, ephemeral nature of cloud-native services. It remains a tempting distractor because organisations often struggle to balance the speed of new deployments with the stability requirements of their existing, long-standing technical environment.

The number of cloud accounts.

Why it fails: The number of cloud accounts is an operational metric rather than a strategic risk threshold. While this figure influences the scope of identity governance and the complexity of Microsoft Entra ID integration, it does not define the organisation's tolerance for financial loss or data exposure. This metric is relevant when performing capacity planning or assessing the administrative overhead of multi-account management, but it fails to address the risk-based decision-making criteria required for establishing an overarching appetite statement for a cloud-native architecture.

Deny

Why it fails: Deny actively blocks resource creation and updates when evaluated resources violate the defined compliance rule, which directly contradicts the requirement to allow deployments to proceed while merely recording the infraction. Administrators often consider this effect when they want strict, immediate enforcement to prevent unapproved configurations from ever entering the environment. It would be the correct choice if the governance policy required outright halting non-compliant resource deployments to maintain strict security baselines.

DeployIfNotExists

Why it fails: DeployIfNotExists runs a template deployment in the background when a resource lacking a desired secondary configuration—such as a monitoring agent—is created or updated, meaning it actively modifies the environment rather than simply generating an audit trail for non-compliance. While this active remediation capability makes it tempting for administrators who want to automatically enforce the presence of dependent resources during deployment, it fails this specific scenario because the requirement asks solely to log non-compliance without blocking or altering the newly deployed resources.

Append

Why it fails: Append modifies resources during creation by adding fields or tags, such as appending a specific subnet to a network interface, which fails this scenario because the objective is solely to log non-compliance without altering resource properties. It is tempting because administrators frequently need to remediate or configure resources automatically during deployment, making it the correct choice when an architect specifically requires automatic field injection rather than simple auditing.

Encrypted email notification system.

Why it fails: While a secure messaging infrastructure is vital for disseminating incident alerts or policy updates to stakeholders across a multi-cloud enterprise, it functions as a communication channel rather than an analytical governance mechanism. A centralised governance, risk, and compliance platform requires automated continuous monitoring, evidence collection, and policy mapping capabilities to evaluate multi-cloud configurations against regulatory frameworks. An encrypted notification system would be the correct choice when configuring downstream alerting routes to distribute compliance violation reports or audit findings to specific administrative teams via secure email protocols.

Manual spreadsheet uploading only.

Why it fails: Manual spreadsheet uploading breaks down entirely in a multi-cloud environment because static, offline records cannot ingest real-time API telemetry across disparate cloud providers to verify compliance continuously. Such manual data aggregation appeals to organisations during initial auditing phases or when retrofitting legacy systems where direct cloud connectors are unavailable, serving as a pragmatic baseline for tracking offline policies or qualitative risk assessments when automated tooling is absent.

Identify

Why it fails: Identify existed in CSF 1.1 and covers asset, risk and vulnerability understanding, not the new supply chain focus. It is tempting because Identify does include supplier-related asset inventory; that would be correct for cataloguing third parties, but CSF 2.0 introduced a distinct function for governing supply chain risk.

Respond

Why it fails: Respond is a CSF 2.0 Core function covering incident response actions, not supply chain risk. It is tempting because Respond does address third-party incident handling once a supplier breach occurs; that would be correct for containing an active vendor compromise, not for the governance function the question asks about.

Protect

Why it fails: Protect focuses on safeguarding assets through established controls like identity management or data security, rather than the overarching governance of external dependencies. It remains a foundational function for maintaining the resilience of internal systems, such as enforcing conditional access policies via Microsoft Entra ID. While this function is essential for mitigating the impact of a breach, it lacks the specific strategic oversight and lifecycle management requirements necessary for addressing the systemic risks inherent in third-party supply chain relationships.